Taiwan's new 'electronic fence' for quarantines leads wave of virus monitoring - <AUTHOR> https://www.reuters.com/article/us-health-coronavirus-taiwan-surveillanc-idUSKBN2170SK <comment><USER2> I'm in Taiwan in day 6 of home quarantine right now. We get a call every morning to check up on our health. I don't mind it, it's a simple and effective method and it gives me confidence in the government and society, knowing that everyone is taking the situation seriously. Once I'm out of quarantine, I can feel comfortable being outside living a normal life, knowing that all known potential carriers are contained.

<comment><USER3> How did they get your information for the daily call? Just curious. Is everyone required to submit contact information? Or did they already have the required contact info for daily health checkups?

<comment><USER4> There is a national registry - if you have a birth certificate, if you have a passport, if you file taxes, if you've used a government service (ever), if you visited dentist/doctor at any point in your life, they have linked those records.

If you are visitor and if they need to, within a few hours of landing at an airport and arriving at your destination, you will get a phone call at your destination location/hotel, etc if the government needs to find you -

Have you ever wondered why you fill out those landing / immigration cards that they give you on the plane? For the US and Canada, those are only formalities. For Taiwan, the cards get scanned in and then the authorities will call the number you put on that card to see if you're there or if you've checked into the hotel, for example.

In regular times, this system is mostly used for things like catching overseas males dodging conscription for example, but the system is active already for times like these when it's critical to know where a person has gone after they leave the airport.

<comment><USER5> > the authorities will call the number you put on that card to see if you're > there or if you've checked into the hotel

So... what happens when you're _not_ there? I.e. if the government just can't find you? Does this then translate to a police APB or something?

<comment><USER6> "My phone, which is satellite-tracked by the Taiwan gov to enforce quarantine, ran out of battery at 7:30 AM. By 8:15, four different units called me. By 8:20, the police were knocking at my door."

[https://twitter.com/MiloHsieh/status/1241540231595044864?s=1...](https://twitter.com/MiloHsieh/status/1241540231595044864?s=19)

<comment><USER5> I meant in the case of a visitor to the country who hasn't purchased a local SIM yet, where the only contact information on the customs form is the hotel's front-desk number.

<comment><USER7> They'd follow you from the airport. You could maybe evade if you were a trained expert who looked like a local national, but otherwise they'd just check CCTV (Taipei is covered in it) and follow your trail. I've never taken public trans out of TPE, so they'd probably just call the cab company and track you down that way. Otherwise, they would check the public trans cameras.

Also lack of local sim doesn't mean you aren't transmitting. It just means the towers are choosing not to provide you with service. A SIM's only purpose is to link your usage to a billing account and phone number.

<comment><USER5> > Also lack of local sim doesn't mean you aren't transmitting.

Yes and no. Airplane mode, turning your phone off, etc.

But also, even if your phone is pinging the tower with your device's IMEI... how would they know it's _your_ phone's IMEI? There's no registry mapping IMEIs to legal identities, in any country, AFAIK. _Carriers_ have that information, but you wouldn't have yet signed up with any Taiwanese carrier. So the Taiwanese government could only get that information from a _foreign_ carrier.

(Yes, you _could_ plug all the tower pings into a graph DB and run Dynamic Network Analysis to figure out what common unidentified IMEI matches the route pattern you extracted from the CCTV data—but you're expecting a lot here; that hardly works even when you have tens of thousands of bits of evidence of e.g. a crime ring; and that kind of analysis is one of the "slow checks", like DNA PCR assaying, that takes months to run— _especially_ if you're having to go process-of-elimination by adding everyone _else's_ IMEIs into the graph to find the "UFO" IMEI [which presumes that doesn't also involve O(N) warrants somehow. I'll be nice and assume it doesn't.] Add the fact that the only people trained in Network Analysis will be in your country's fraud squad, and someone between Customs Enforcement and Fraud will have to come up with the idea of getting the fraud people to use this technique outside of its usual domain of application, and... not seeing it happening.)

Basically, for the Taiwanese government to know your phone's IMEI, you would have either had to tell them the IMEI on the customs form†; _or_ they would have to ask your previous phone provider _in your country of origin_ what IMEI _they_ last saw registered to your IMSI (in turn attached to the phone number on your customs form); and then, _provided your domestic provider had any reason at all to want to answer that question_ (they certainly wouldn't be _compelled_ to), _then_ the Taiwanese govt would be able to track you.

But that helps nothing if, again, you just provided the phone number of the hotel you're staying at as your "contact number" on the customs form, as they ask you to. Then they'd need to take another step back and figure out _what your cellular numbers in regular use_ are, given only your other details, without even knowing what carriers you have relationships with in other countries. (Sure, okay, look it up on LinkedIn. That works for a normal person. I'm assuming a person motivated to hide here.)

It also helps nothing if you bought a new phone at any point between when you last signed up for a SIM in your last country of known residence, and when you showed up in Taiwan; and it _also_ helps nothing if you just set your phone to spoof your IMEI. (IMEIs are like MAC addresses: a hardware-fused default with a software-programmable override!)

† ...or they could read it off the millimeter-wave scan of your phone they took at the airport, if they tune the scanner just so. That solves everything for them except the IMEI spoofing, really.

<comment><USER4> This is probably thinking too high tech for some basic human int collection. It's easy enough to collect imei numbers at a checkpoint. It's also easy enough to find out from family members and friends and business connections (everyone works for someone, has a family, and friends, and even if none, there's always a bank account that paid for the airline ticket somewhere, attached to a passport).

Think low tech. Taiwan didn't even have a computerized registry when I was born, so everything was done by hand (I can confirm this because when I had to look up my birth certificate, it wasn't in the records! and they had to look up the records by hand - but the records exist and are easily findable by humans)

also, don't neglect a simple phone call from the police to your boss - that's a super easy way to find out what's going on. Especially for Western folks who seem to be tied to their work.

<comment><USER5> > It's easy enough to collect imei numbers at a checkpoint.

True enough, I guess. Require that you turn all devices on, then either require unlock and look at the IMEIs yourself, or pass the person through a Stingray in an RFID cage.

But I would assume that if Taiwan _was_ doing that, people would notice (requiring turning devices _on_ is a very unusual step) and would have mentioned online somewhere that that's something that happens when you visit Taiwan.

Also, it still won't help if this immigration-evader turned super-spy is rolling their spoofed IMEI regularly.

(Also, where would they get the information on who your boss/company is? From your customs form? That's one of those things too expensive to verify for every case ahead of time, so they won't bother until they actually want to find you; in other words, that's one of those things that's perfectly easy to lie about. From your visa, presuming you need one? Information like that could be entirely outdated by the time you visit.)

<comment><USER4> "Also, where would they get the information on who your boss/company is?"

They ask you at the customs checkpoint. Human intelligence collection is the custom official's job. Even when coming through Canadian Customs border, they do (and are able to) ask directly: who do you work for. What do you do? What is your job? Do you have family here? Where do you live? How old are you?

Those are level 1 questions for crossing the border at pretty much any country.

Driving through the Peace Arch border crossing into the US, I've been asked all of those questions.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Like other people are saying, there's definitely ways around this. The only reason why Taiwan has been so successful in battling Coronavirus is that there is national pride in acting as a whole and doing what's best for society. There is huge shame to the family for people who defy. Taiwanese people generally know what helps society and when to listen. It is the cultural influence/mix of Chinese and Japanese governments which are deeply ingrained. Source, I am Taiwanese.

<comment><USER9> I don't think it's only culture and this just happened by itself. The leadership of President Tsai Ing-wen (蔡英文) surely was a factor as well.

Culture works in conjunction with good policy and leadership. I would be wary of attributing too much to the relatively immutable and hand-wavy notion of culture.

<comment><USER10> Their VP is also an epidemiologist by training, a public health researcher, and was the health minister during the SARS epidemic [0] so definitely seems like the right person in the right job at the right time.

[0] [https://en.wikipedia.org/wiki/Chen_Chien- jen](https://en.wikipedia.org/wiki/Chen_Chien-jen)

</comment></comment></comment><comment><USER11> Yuval Noah Harari (author of Sapiens) wrote a piece [1] on how we're now facing a choice between authoritarian surveillance and citizen empowerment, and how a decision made in this crisis could set the standard for the future.

[1] [https://www.ft.com/content/19d90308-6858-11ea-a3c9-1fe6fedcc...](https://www.ft.com/content/19d90308-6858-11ea-a3c9-1fe6fedcca75)

<comment><USER12> A fascinating counterpoint to this is the German government, who not just as probably the first country did something distinctly different to quarantine (it's called contact prohibition and you can go anywhere you like as long as you don't meet with more than one person not from your household), but also rejected mass cell phone surveillance plans by a large margin.

People here are mostly calm, cautious and despite a few outliers have largely high compliance rates from everything I see on the streets.

More authoritarian governments have the clear upper hand in fighting COVID-19, but I'm very curious how this will play out and if we can weather this situation just as well as a free and privacy-sensitive liberal democracy.

<comment><USER13> >> _People here are mostly calm, cautious and despite a few outliers have largely high compliance rates from everything I see on the streets._

Shouldn't the virus spread little by little so people gain immunity and the hospitals can manage the number of patients? I doubt we can continue this shutdown for 12-18 months (vaccine) and who knows if meds cure it.

<comment><USER14> It is possible that immunity doesn't last forever. There could be a second wave in the future.

</comment></comment></comment></comment><comment><USER15> Tracking like this has been one of the reasons for Singapores success to curbing the virus.

[https://www.therakyatpost.com/2020/03/23/what-malaysia- can-l...](https://www.therakyatpost.com/2020/03/23/what-malaysia-can-learn- from-singapores-handling-of-covid-19/)

""If people don't have symptoms, they're put in home quarantine. And home quarantine is very strict. A couple times a day, you'll get an SMS and you have to click on a link that will show where your phone is.

In case you cheat and leave your phone at home with someone else, the government has people knocking on doors now and then. The penalties are pretty harsh. ""

<comment><USER16> There was a Chinese person in Singapore who had PR and refused to follow the quarantine order.

They took away his PR status.

<comment><USER17> PR?

<comment><USER15> Permanent Residence

thats good. Rules are rules, especially in these times.

<comment><USER18> That's terrible. PR is supposed to be "more or less a citizen, now stay for long enough and you can become a citizen".

Not "we'll call it permanent but it doesn't mean anything".

Rules means justice and enforcement too.

You're not supposed to have a different justice system for people on PR than for citizens. They should have jailed the person, if that's what they do to citizens, or done whatever else they do to citizens who break the rules.

<comment><USER19> Not at all. You still need to renew your PR status over time. It's only permanent in the sense that if you are free to live in the country without needing to be sponsored by someone (company or individual). It's still a visa at the end of the day.

If you're on an EP / WP which is then cancelled you have 30 days to get a new visa or leave the country.

PR != Citizenship in any shape or form.

<comment><USER18> > PR != Citizenship in any shape or form.

Regular administrative renewal, yes, but aside from that, I guess my complaint is that PR should resemble citizenship better, in matters of justice and in other matters.

People live in PR status for an extraordinarily long time. Decades. Sometimes their whole life after obtaining it.

Nobody should be have to live their lives in "second-class person, second- class justice" mode for such a long time wihout being able to lay down roots. It's not good for individuals and it's not good for society, and it's not right.

The same applies to partners or spouses of citizens.

Generally if you're an immigrant partner or spouse of a citizen, you live a second-class life, with second-class justice and second-class healthcare, because you know everythig you have can be taken away by one bad domestic argument. All it takes is uncertainty about a breakdown of the relationship for you to be remainded that you can lose just arout everything you have and value in life. So suck it up and be a good wife/husband, now fetch me my dinner etc.

There should at least be reasonable time limits on such second-class status, purely on moral and natural justice grounds.

<comment><USER19> There is alot of negativity towards PR in Singapore because Citizens often feel that PR get too many benefits that they never feel the need or want to give up their own citizenship in favor of Singapore citizenship.

Alot of the benefits of PR have been taken away or reduced over the last 8 years that i've lived here.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'm in precautionary quarantine in Taipei right now, after arriving from a Level 3 country some days ago.

As a tourist, I had to provide a phone number of a contact person in Taiwan upon my arrival. They call the number and confirm it works before you even leave the CDC checkpoint at the airport. You also self report your health condition. I then stood in line for 4 hours to get a special taxi to my place of quarantine. Taking public transport is forbidden. Before finally getting into the taxi, I was sprayed all over (including the bottom of my shoes) with with I presume was disinfectant.

I was later requested to add a police officer on the social media platform Line, through which I'm now asked daily how I'm feeling, and offered help if I need anything. However I don't think they can track my position through it.

There's a stall selling cheap SIM cards for tourists at the airport, but it's past the CDC checkpoint, so no tourist has a local number to provide. Perhaps they should move it upstream (and just provide the cards for free), if they want this "electronic fence" to be watertight. I'm not sure but I think I could technically go wherever I pleased right now.

<comment><USER21> I'm curious as a tourist what happens if you don't have a local contact? What happens if one has nothing but a hotel booking for accommodation instead of a home? I'm guessing that wasn't your case but were there others you heard or saw who were just regular tourists?

<comment><USER20> Actually my local contact was simply my Airbnb host. I had arranged the Airbnb only earlier that day, In response to the new travel restriction.

Other passengers provided the number of their hotel. The CDC called the hotel and (I believe) checked whether they were aware that these passengers were about to self-quarantine there.

Edit: even if you arrived without having anything booked at all, you can pay to stay at a designated quarantine hotel, though that is more expensive.

Also note that Taiwan doesn't grant the "visa exemption" usually granted to tourists, when they now arrive from countries assessed as level 3 (requiring home quarantine). I was able to enter during a short window of time where home quarantine was instated but the new visa rules were not yet in effect. So I think it isn't usual for the situation you described to occur.

<comment><USER21> I'm curious were you traveling around Asia anyway and decided to visit Taiwan due to the Coronavirus being very contained there? Are you seeing lots of other travelers? Is your plan to wait it out there if so? It doesn't seem like a bad place to be right now.

</comment></comment></comment></comment><comment><USER22> > Quarantine violators can be fined up to T$1 million ($32,955).

Today Taiwan fined a guy $33k USD for breaking quarantine by going to a nightclub (not a positive COVID case just a mandatory isolation due to travelling):

[https://asiatimes.com/2020/03/heavy-fine-for-taiwan-man- for-...](https://asiatimes.com/2020/03/heavy-fine-for-taiwan-man-for-breaking- quarantine/)

They aren't joking about the fines.

<comment><USER23> small correction: NTD$100,000 (usd$32,955)

Taiwanese Dollars isn't that shitty (yet)

<comment><USER24> US$1 ~ 30.2NT so the original numbers seem correct.

</comment></comment></comment><comment><USER25> Why would such a mechanism of control incentivize those that feel sick to report their symptoms? Why would one submit to control at this level?

This sound similar to ankle-bracelet-level Parole / house arrest structures. In fact, I'd prefer that because it would only be providing a single source of sensor data to the government instead of possibly making my entire phone and location history accessible.

<comment><USER26> It works well enough if everyone considers the best of their society as more important than their own freedoms. So it's pretty easy to extrapolate where this might work and where it would be fruitless.

<comment><USER27> The libertarian types who think the gov't shouldn't exercise this kind of authoritarian power also think their plan is the best for society.

<comment><USER28> As a "libertarian type" well out on the left, I see the simple resolution to this that if you're prepared to risk the health of others, you're free to do that as long as you do it with other consenting adults apart from the rest of us, and expect not to be allowed contact with the rest of us until its safe.

Freedom for everyone also means freedom for people to band together and decide not to want anything to do with those who don't want to follow their rules.

Especially in this case, where the health risk arguably makes it aggression to try to force contact on others.

</comment></comment></comment></comment><comment><USER29> > The system monitors phone signals to alert police and local officials if > those in home quarantine move away from their address or turn off their > phones. Jyan said authorities will contact or visit those who trigger an > alert within 15 minutes.

> Officials also call twice a day to ensure people don't avoid tracking by > leaving their phones at home.

I'd hate this so much. I get why they feel it's necessary, I do. But I still absolutely hate this.

I hope stuff like this doesn't get nomralized. Especially in other non-first- world countries

<comment><USER30> People love it. The amazing shift in online rhetoric that praises authoritarianism is scary.

Imagine this being rolled out for the flu.

<comment><USER31> If the flu caused the kind of havoc to our medical systems that COVID is causing, I'd want this rolled out for the flu, too.

<comment><USER32> flu already was wreaking massive havoc, it's just a cost we've internalized. Like driving.

<comment><USER33> Part of that is having the hospital capacity for seasonal flu and accident victims. We're prepared for that. Coronavirus adding more cases will soon overwhelm hospitals in major US cities, at which point they will have to start triaging patients like they are in Italy.

Presumably if this became the new norm then we would up our hospital capacity to match and then re-adjust our life expectancy numbers as well.

<comment><USER32> we don't have the hospital capacity for seasonal flu victims.

<comment><USER33> By capacity I mean during flu season we don't run out of hospital beds when people with serious flu complications need them.

By that definition then "not having capacity" means that people who go to the ER have to get turned away based on medical triaging.

<comment><USER32> Hospitals often have to set up tents in parking lots to deal with flu cases when the influx is much higher than average. We don't provision for peak flu; we provision for something less than the flu average.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> Taiwan doing this = effective. china doing this = creepy. however, probably necessary in both cases. perhaps a rhetorical cease-fire globally would benefit us all.

<comment><USER35> One of those countries is an authoritarian "communist" state with a well oiled dissent suppression machine.

<comment><USER36> Please don't take HN threads further into nationalistic or ideological flamewar.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment><comment><USER37> Taiwan is trying really hard to attract foreign talents to boost their economy. If you're interested, check their Golden Card Permit. It's a visa+redisent card allowing you to stay and work for anyone there up to 3years. The only requirement is to justify of a an average salary of 160k NTD/month(~USD 5210/month), anywhere in the world. If you don't earn that, try the skills application[1]. I'll not talk about all the positive things about Taiwan, just read the other comments.

[1] [https://foreigntalentact.ndc.gov.tw/en/cp.aspx?n=128B875DE9C...](https://foreigntalentact.ndc.gov.tw/en/cp.aspx?n=128B875DE9CBEBE3&s=0FCDB188C74F69A0)

</comment><comment><USER38> I wish we had that in the US. We're about to begin the Great Dieoff.[1] That chart now updates every day at the URL, and is worth following.

[1] [https://www.ft.com/coronavirus-latest](https://www.ft.com/coronavirus- latest)

</comment><comment><USER39> > the system has drawn few [privacy] complaints in Taiwan

Yeah until after the coronavirus craziness is over and the (now tested) system is used by China to round up dissenters

<comment><USER40> You know this is an article about Taiwan right?

<comment><USER39> Look up the history of Taiwan and China.

<comment><USER41> Are you implying that China would hack the Taiwanese system and use the data to somehow identify dissenters within mainland China?

<comment><USER39> No I'm implying that China probably already has a backdoor built into this system and could strategically use it to further their Taiwan -control agenda.

<comment><USER41> > _is used by China to round up dissenters_

Where are these dissenters? China, Taiwan, or elsewhere?

</comment></comment></comment></comment></comment></comment><comment><USER42> I wouldn't feel comfortable being stripped of the right to have no phone.

<comment><USER43> Then don't travel to Taiwan for a few months.

<comment><USER42> What about the rest of the time? Is it easy to live without a phone in Taiwan? Can you buy a non-locked phone and a prepaid SIM card anonymously?

<comment><USER44> Only if it's an a SIM purchased from abroad. You need to produce a form of national ID if you want to purchase a SIM in Taiwan.

</comment></comment></comment></comment><comment><USER26> It's good that everyone sees and learns what these systems are and what they can be used for. Hopefully everyone can figure out what they can be used for, if used for the wrong purposes.

</comment><comment><USER45> Good thing phones are embedded into us and can't simply be left at home.

Joking aside, and I suppose privacy concerns aside, this measure is better than nothing and is also less draconian than the physical enforcement by police that was seen in mainland China.

<comment><USER46> Fifth paragraph: "Officials also call twice a day to ensure people don't avoid tracking by leaving their phones at home."

<comment><USER47> good thing phone forwarding isn't a thing

<comment><USER48> The threat here is more "I'll just run to the store real quick; nobody will even know" than "We need to thwart determined criminal masterminds."

<comment><USER47> yes, of course.

i was just responding in the tone of the thread

</comment></comment></comment></comment></comment><comment><USER49> I just want that this COVID-19 phase pass out and all the people to be cured. Doctors from all over the world are working for the cure and hope they find it!

</comment><comment><USER50> Kind of incredulous seeing how many people are ready to forfeit all their freedoms so willingly. Simply can't wait for the government to keep us safe in our electric pens.

<comment><USER24> In Taiwan, shops / restaurants are open as normal and people are walking around freely, other than the tiny percent in quarantine. Meanwhile Europe and the US are increasingly locked down. So which one has more freedom?

</comment></comment><comment><USER51> american exceptionalism! lol

</comment><comment><USER52> > which has reported only reported 108 cases of the virus

absolutely amazing

<comment><USER53> According to this site it is 215 now (March 23):

[https://www.worldometers.info/coronavirus/](https://www.worldometers.info/coronavirus/)

This is just 3 days after the publication of the Reuters article, so it seems like it may be growing at similar rates to elsewhere (doubling every 3 days), just from a low base?</comment></comment>


Ask HN: Can I not accept Oculus' new ToS? - <AUTHOR> I bought my Oculus Rift before Facebook purchased the company, and I don't have a Facebook account. Is there anything I can do about my hardware that is about to be bricked? <comment><USER2> I thought you could continue to use your existing account without switching to a Facebook account.

I just got an email that says:

"On that date, you will have the choice to continue using your existing Oculus account and remain under the updated Oculus Terms of Service and Privacy Policy, or to use a Facebook account on the platform and agree to new terms. Learn more."

<comment><USER3> The announcement blog post[1] includes this line:

"Will a Facebook account be required to use future Oculus devices? Yes. Future Oculus devices will require a Facebook account."

My current understanding is that new devices, such as the Quest 2, will also mandate the use of a FB account.

[1] [https://www.oculus.com/blog/a-single-way-to-log-into- oculus-...](https://www.oculus.com/blog/a-single-way-to-log-into-oculus-and- unlock-social-features/)

</comment></comment><comment><USER4> Does it literally brick your hardware, or do you just lose access to the Oculus store or something similar, and can still use it as a generic VR headset?

<comment><AUTHOR> As far as I understand I can't get back into the Oculus Hub where I bought my VR titles. The VR headset will still work, I just can't use it on software I bought.

</comment></comment><comment><USER5> The Oculus situation reminds me of this video: [https://youtu.be/q2LIXcbDiZA](https://youtu.be/q2LIXcbDiZA) which predicted the future.

</comment><comment><USER6> Likely not the answer you're looking for ... I was in the same situation as you. I just sold mine.

<comment><AUTHOR> Yeah, think that's my only solution as well.</comment></comment>


Erlang and First-Person Shooters (2011) [pdf] - <AUTHOR> http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf <comment><USER2> I saw this deck mid-2014, and it single-handedly made me want to learn Erlang. I felt that any system that can handle COD's load is, at the very least, worth checking out.

About a year later, I got a job doing Erlang full-time, and OTP is about as good as that slideshow indicated...So, if anyone at Demonware is reading this...Thank you! You introduced me to my second great love (after my wife)!

<comment><USER3> How did you get into erlang, like in project wise?

Because I played around with rabbitmq plugins, a nehe opengl examples port and some erlang notepad someone implemented. I also own both o'reilly hard copies.

But other then that I don't really have a project I can see myself use erlang for(one man shop).

<comment><USER2> The Cowboy webserver is fairly easy to get started with and I really recommend checking it out, since a web server feels like a "very Erlang problem" to me.

To answer your question though, I got started by playing with TCP and building a basic chat server. I spawned a new Erlang process for each user, used Erlang's internal messaging to share messages between processes, and then passed those messages along to TCP to the user.

A basic rule of thumb on whether or not it's a good Erlang problem is seeing if you can visualize the problem in terms of a bunch of tiny, self contained things (like cells), and you don't want one of those cells failing to have any risk of breaking anything else.

<comment><USER4> Got a good book or website recommendation for learning Erlang?

How does it compare/contrast with something like Akka (which I've got rudimentary experience with in Scala)?

<comment><USER5> Akka was basically the Scala implementation of Erlang's actor model.

The key differences are, for me, Erlang is easier to reason about (this is mostly how my mind works; Akka it felt like everything was reactive, that nothing is doing any work until it gets a message; Erlang it felt like the opposite, that every process is doing work until it decides it needs a message, and then it can check its mailbox, and optionally block until something ends up in it), and because of its functional nature, things that require special keywords in Akka, just fall out 'for free' in Erlang. For instance, 'become'. 'Become' is just calling another function in Erlang, that has different behavior. Erlang also has more reliability characteritics (not as efficient, but, no stop the world garbage collection, shared nothing, so the only way an exception in one actor can affect another is via an OOM, or specifically hooking up links/monitors such that it causes it to affect the other actor). Akka, however, gives you the speed of the JVM (which -is- better, in pure number cruncing, than Erlang), more libraries (though Erlang is no slouch there, and they all kind of fit the Erlang model), and OOness, if that's your thing.

</comment></comment></comment></comment></comment><comment><USER6> From a gamers perspective, the peer-to-peer lobby system used in the CoD series is one of the worst things about it.

I can remember constantly having to migrate hosts, getting owned by the host because everyone else has a ping much higher than zero, and horrible lag when the host it chose had a bad connection.

Cool technology, but at the cost of fun.

<comment><USER7> Eh, I played CoD for a long time in middle and high school The community loved to complain about the whole lack of dedicated hosting thing but I rarely had bad experiences with it. Plus, CoD 4 and CoD WaW both had dedicated servers but are mentioned in this slide deck, so it sounds like they'd be using this middleware regardless.

At CoD scale I'm sure the ability to not rely on first party hosted servers saved enough money to justify the occasional service interruptions, and this system is better for groups of players that might be close to each other but far from an official data center.

</comment></comment><comment><USER8> I wonder if they have considered moving to elixir since some of the problems they have highlighted are resolved in elixir.

That would be easier for new employees and they could still keep their Erlang code base until they make the full switch.

<comment><USER9> I'm wondering the same :)...

<comment><USER10> In 2011 Exlixir didn't exist. More than likely they've stuck to Erlang as the incremental benefit is really on the language side only. If you're only moving to Elixir because of the language sugar, the only thing you're going to gain is maintenance and updates -- with a system that probably doesn't need all that much in the way of "tinkering".

<comment><USER11> Elixir doesn't just add "sugar" though; it has full-fledged first-order macros, through-and-through UTF8 support, sensical argument placement (the thing being acted upon is always the first argument, making possible the |> operator), sigils, great tooling, and possibly best of all, the best Rubyists are fleeing to it. ;)

</comment></comment></comment></comment><comment><USER12> Keep in mind that those are online services and can be developed in every languages since it's not hard real time ( aka C++ gameservers ). Most online services for the video game industry are actually made in Java.

<comment><USER13> Game servers don't do hard real time. That would be overkill, and requires specialized operating systems typically used for niche applications like robotics; e.g. [https://en.m.wikipedia.org/wiki/RTLinux](https://en.m.wikipedia.org/wiki/RTLinux)

<comment><USER14> I've been reading up on VR after trying an Oculus Rift. It sounds as if VR game servers will need something a bit closer to "hard" real time than current servers. I suppose it still wouldn't technically be "hard real time" but much "firmer real time". I guess this leaves me wondering if games will ever progress to needing "hard" real time.

<comment><USER15> That doesn't make much sense, think about lag, playing with somebody who is far enough that the speed of light makes a difference. You want a near real time graphics pipeline for each user to avoid vomiting, but other than that you will still get terrible terrible network problems one way or another which you can't control and will show up as ghosts in the game, stopped players, etc.

</comment></comment></comment></comment><comment><USER16> Question for those of you who are game programmers. Is the message passing of erlang slower than shared memory threads in c++?

<comment><USER17> Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book.

I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good for some things, and probably exceptionally good at what Erlang was designed for (Telecom systems), but I think they're just one tool in the toolbox. If the recommended solution for CPU-bound tasks is to start writing C, I have to wonder if there's a better way.

<comment><USER18> Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.

<comment><USER19> Lock based concurrency is perfectly fine on 800 core systems with a _pauseless_ gc and many TiB heaps. See Azul for an example using the JVM.

</comment></comment></comment></comment><comment><USER20> here is the video of the talk: [https://vimeo.com/26307654](https://vimeo.com/26307654) and hopefully, provides a nice complement to just going over the slides...

</comment><comment><USER21> Since some people were asking on how to get started with Erlang, some time ago this MOOC was posted on HN for an intro to learning Erlang/functional programming.

What I liked about it is that it assumes you have an imperative programming background so it isn't entirely like learning at a very slow pace (which leads me to lose interest): [https://www.futurelearn.com/courses/functional- programming-e...](https://www.futurelearn.com/courses/functional-programming- erlang/)

The next course after this is on the concurrency part of Erlang which is also on FutureLearn that I'm currently taking. It has video clips from Joe Armstrong teaching concurrency (one of the creators of the language).

</comment><comment><USER22> An important take-away is that's it's very hard to know the bottlenecks beforehand. As an experienced programmer you can have a hunch, but you still need to test and measure.</comment>


Show HN: Crowdfunded inventory for small businesses - <AUTHOR>

We were a part of Boomtown Boulder's second accelerator class, and after a few months of thrashing and pivoting, we feel we've got something pretty cool! We are a new crowdfunding platform with a twist - we let you partner with retail businesses by financing their inventory, helping them with marketing/lead generation and then collecting a return when that inventory sells. What I am personally really excited about, is that because the users are actively engaged throughout the process, this type of investment is not classified as a security and we can offer it to non-accredited investors. It's also a pretty unique solution for the businesses as they essentially get their inventory fronted to them at no cost, freeing up their cash for other business activities. Would love any feedback on anything, our site is: http://www.kickfurther.com <comment><USER2> You've got a small problem with your CSS. You set a reasonable font-family early in the body{}, and then later in the stylesheet, you overwrite it:

[http://www.kickfurther.com//stylesheets/app.css](http://www.kickfurther.com//stylesheets/app.css)

      app.css:62
      body {color: rgb(34, 34, 34);
        font-family: "Helvetica Neue","Helvetica",Helvetica,Arial,sans-serif;
        font-weight: normal;font-style: normal;line-height: 1;cursor: default;
      }

      app.css:8219
      body {font-family: "proximanova",sans-serif;}

In that one file, there are 286 styles where you go mucking about with the fonts (size, family, weight, ...). This is bad juju since it means a ton of work for the web browser, and hence, a slow site.

The main background image fails to scale on a slightly older version of firefox I tested (18) when resizing the browser window, but it worked when tested with an older version of chrome (24), it scaled properly. I think the issue is with how you're setting background-size here:

      app.css:9203
      .homepage {
        background-image: url(/images/homepage.jpg);
        background-size: cover;
        padding: 5.25rem 0 9.5rem;
        color: #FFF;
      }

A quick check of ff-18 on the quirksmode test for "background-size" [http://www.quirksmode.org/css/backgrounds- borders/size.html](http://www.quirksmode.org/css/backgrounds- borders/size.html) doesn't show anything odd, or shed any light on the scaling issue. My bet is this is a (old) firefox problem resulting in the usual battle of attempting to support outdated browsers. --I'm not sure how much effort you want to put into legacy support? (It's a losing battle ;-)

The layout/design is intentionally large, spread out, and with lots of empty space. It takes effort (read: friction) scrolling down to figure out what KickFurther is all about due to all the empty space. It has nice calls to action for both individuals and businesses, yet without knowing what it's all about (i.e. the calls come before "How does it work?" section), I question how effective they will be? (i.e. conversions). --You might want to A/B test putting something like the "How does it work?" earlier or even first along with the text over main background image e.g. Initially state the problem you solve (providing capital for inventory to businesses), _and how you solve the problem_ (crowdfunding inventory purchases).

The rotation animation on the logo is a nice touch and it looks good.

It takes too much effort to get to the menu items on the bottom of the page, and they are rendered in a font that's too small. The menu item links like "FAQ" "Screen Process" "How it works" and even "About Us" are deserve more emphasis. --Your concept is new, but the first thing I wondered about is, "How do they prevent fraud?" so who you are and how you screen users should be emphasized more (IMHO).

[http://www.kickfurther.com/offers](http://www.kickfurther.com/offers)

On the "Offers" page, I'm not sure what to think about the blurred out offer images under the "Upcoming Offers" header. It was unpleasantly annoying to be tricked and driven towards joining your mailing list and/or registering in this way. It might be effective, but...

All in all it's an interesting concept and I've never seen it before. Good luck with it!

<comment><AUTHOR> Hey thanks for the great feedback! Was that a knock on proxima nova? ;) We definitely need to optimize the css, 10,000 lines is silly for what's on the site right now. I'm using foundation and not selectively including components at this point so that would be an easy first step. I'll look at the background issue as well, it needs to be cleaned up in general and is not currently optimized for mobile either.

I definitely agree about needing to make the messaging more direct right up front, that has been one of our biggest challenges throughout. We want to experiment with different landing pages of course, and are working on a 'how it works' video to stick at the top of the homepage as well.

Great notes on the footer links, we need to find ways to make that information more accessible and easy to find in general. I also wasn't a big fan of the blurred out offers, we just didn't want that page to feel too empty; we'll get rid of it once we get a couple more offers live!

<comment><USER2> > _" Was that a knock on proxima nova? ;)"_

No, not at all! --I'm not particularly bright and I love warm weather, so it sounds like fun to be in the general proximity of a nova. ;)

I hope I wasn't too critical? Writing replies to "Show HN" posts can be tough to balance since the intended goal is to get/give useful feedback.

As for fine-tuning your messaging, you're in uncharted waters with an entirely new concept. It will take some effort and time (and A/B testing), but keep at it and you'll get there.

<comment><AUTHOR> Not at all, we appreciate the critical eye.

</comment></comment></comment></comment><comment><USER3> I love the idea, but aren't you worried about the name causing trademark issues?

<comment><AUTHOR> Thanks! We don't think Kick______ can be trademarked, but if it gets to that point we're not too worried about having to rebrand.

</comment></comment><comment><USER4> Man, this is genius. I hope you succeed, but it is so awesome that I can't stop thinking there is some problem with the idea (I'm not seeing any, but, hey, it is too good to be true!).

<comment><AUTHOR> Thanks!</comment></comment>


4G data: The USA is second-slowest while Australia is fastest - <AUTHOR> http://thenextweb.com/mobile/2014/02/20/4g-data-usa-second-slowest-australia-fastest/ <comment><USER2> Sure, that's true. However, 4G is completely patchy across Australia.</comment>


Google fired engineer for breaking internal privacy policies - <AUTHOR> http://techcrunch.com/2010/09/14/google-engineer-spying-fired/ <comment><USER2> I'm going to temporarily put aside what this guy did (which is really bad, but people with bad intent aren't common), to discuss what this tells us about Google (which is about The System, and cause for larger concern).

If anybody from Google can (anonymously if necessary) step in and answer questions, it'd be great.

* Different gmail accounts. Google knows they're all you.

In the original Gawker story, this caught my eye:

"...pulled up the person's email account...[and] a list of other Gmail addresses that the friend had registered but didn't think were linked to their main account—within seconds"

Keeping separate Gmail accounts is how many protect against "Google knows everything about me." In fact on Google's "What Google knows about you" page, it never crosses accounts (unless you've manually connected them). This story basically tells us the "What we know about your account" page is a bit misleading. Of course most folks in IT know it's a bit naive to think one could never figure out that different gmail accounts are related. But it was interesting that Google pretty formally knows the relationship, but doesn't tell you right where it should.

* SREs, and their level of access.

It's not so much that I care is a specific group has lots of access. I care that not that many groups do in total. This story makes me concerned that actually many groups have lots of access. Despite the "elite navy seal" vibe presented in the Gawker story about SREs, I'm now thinking that many, many teams have this kind of access. (Previous to this story, I was led to believe that SREs were quite low level (not in importance. but in nature of responsibilities. Very performance oriented, having little reason to have access to an individual user's data.).

Please feel free to jump in and correct this, Google peeps. It would make me feel better.

* What this does for SaaS and web apps in general

I love Google Docs and sincerely believe that most web apps that allow across- the-net collaboration are good for us. And are preferable to The Old Way. I want people to TRUST their stuff to Google (and Github and Amazon, etc).

I hate security FUDers who love to derail conversations of great possibility with some far out scenario, "Can my enemy see my Google Docs?!?!"

I'm way less worried about a few creeps who work at Google (they work everywhere...) and more concerned about laissez-faire access processes.

<comment><USER3> _"...pulled up the person's email account...[and] a list of other Gmail addresses that the friend had registered but didn't think were linked to their main account—within seconds"_

This surprised me too. In the absence of any further comment from Google, I'd be very interested to see some journalists doing some investigation here.

Assuming that this is real and not mis-reporting or user error, I'm guessing Google links using either their google.com cookie, IP address and/or browser identification. Any of those methods have potential for errors (in particular they mean you should never share a _browser_ with another person in case your account ends up linked. That seems.... extreme..)

<comment><USER4> Not a journalistic investigation, but a while back I decided that I need a new gmail account. I signed it up using some different credentials, including a different name. However, I did not mention my old gmail account in the entire sign-up process. After I activated my new account, I got an email on my old account referencing the new address I just signed up for and a verification code "in case something happens."

From this it seems to me like this is not a deliberate maneuver to deceive, but rather just an oversight.

<comment><USER3> I have a second gmail account (in the olden days that's what they recommended on <http://code.google.com/apis/gadgets/docs/publish.html> \- I see now that they have switched to using filters), and this didn't happen to me.

Are you sure you didn't use the first gmail account to send an invitation? Because in that case it does add the address to both accounts address books.

</comment></comment></comment></comment><comment><USER5> He was fired? That's all?

From all reports, it seems that this Google employee accessed data which he knew he had no authorization to access. That sounds like a textbook case of computer crime -- why hasn't he been arrested yet?

<comment><USER6> He did have authorization to access it. He didn't have authorization to abuse it in the way that he did. It's all kinds of icky but what do you think was so obviously criminal about it that you expect him to be in jail?

<comment><USER5> Unless Google's policies were written by bungling idiot, Barksdale would have authorization to access _information required for him to fulfill his duties_. The information he accessed very obviously goes well beyond such authorization.

<comment><USER6> Well. We can get into a silly discussion about what 'authorization' means, I just don't understand why you find this so obviously criminal. Remember these idiots -

[http://www.pcworld.com/article/154392/snoopy_verizon_employe...](http://www.pcworld.com/article/154392/snoopy_verizon_employees_fired.html)

Didn't get charged, let alone arrested, either.

</comment></comment></comment></comment><comment><USER7> Regardless of how Google is playing this in the press, the question people need to be asking isn't about the rogue employee. It is: "what are the controls being put in place to prevent SRE's from accessing sensitive data inside Google apps, and what specific forms of information is Google considering sensitive for those purposes, and is there a class of employee at Google that is expected to be exempt from these controls?"

<comment><USER8> And Google has answered that question. See [http://techcrunch.com/2010/09/14/google-engineer-spying- fire...](http://techcrunch.com/2010/09/14/google-engineer-spying-fired/) for the following passage:

 _We dismissed David Barksdale for breaking Google's strict internal privacy policies. We carefully control the number of employees who have access to our systems, and we regularly upgrade our security controls–for example, we are significantly increasing the amount of time we spend auditing our logs to ensure those controls are effective. That said, a limited number of people will always need to access these systems if we are to operate them properly–which is why we take any breach so seriously._

I would assume that the logs he is talking about are logs of accesses made by Google employees to data covered by the privacy policy.

(Disclaimer, I am an SRE at Google. I do not speak for Google.)

<comment><USER7> First hit: [http://jobs.metafilter.com/173/Site-Reliability-Engineer- at-...](http://jobs.metafilter.com/173/Site-Reliability-Engineer-at-Google)

Required Skills/Qualifications:

* BA/BS in Computer Science, MS or PhD is preferred.

* 0-15 years experience.

* 3+ years developing web-based applications.

<comment><USER8> You left out most of the credentials that were listed in that ad. And I don't think that anyone believes that every SRE who has the paper credentials gets hired.

Also most SREs don't get access to the same things that this guy did. (What you get access to depends on what you're working on.)

<comment><USER7> The rest of the credentials were skills-based, except for that last one, which suggested that some management skills would be a nice-to-have. Do you take my point about how "SRE" isn't a very strong answer here?

<comment><USER8> I think you don't know what you are talking about here.

It is like someone seeing an ad for entrepreneurs that says, "Willing to work. Willing to take risks. Strong computer skills a significant plus"." And then concluding that the bar to being a successful entrepreneur is very low so they should be dismissed as a group.

Becoming an SRE is much, much harder than just having the credentials you listed. Being an SRE generally does not give you full access to everything at Google. I never met this one, so I don't know what his role was or why he was given that level of access. But that access really isn't something that just gets handed out to people off the street.

The fact that you found that ad, and that Google screwed up this particular case, doesn't say that Google doesn't limit who gets access to sensitive data.

<comment><USER7> I think you're extrapolating too much out of my comments. I'm saying that "SRE is an important job" doesn't answer the concern. I'm not surprised that Google has controls beyond "you're an SRE, you can do whatever you want" --- in fact, I'd be shocked if they didn't. But it sure sounds that way from the story that just broke yesterday.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> At first glance, google comes off pretty good on how they dealt with this, but you have to wonder how come a single engineer has access to google voice _and_ google mail and IM data of end users. SRE's as these employees are labeled (site reliability engineers) are 'highly experienced engineers who can be trusted'.

It goes beyond just snooping too, apparently this guy changed end-user settings which had specifically made to lock him out, and spent a lot of time and effort to use his position at google to achieve real world effects with the people he was snooping on.

This guy has a serious case of sysadmin god complex and while I'm really not sure if it is ok for him to be exposed with name and picture I hope he'll never be in a position of such responsibility again, and I hope that google will perform better oversight of the people that have access like this.

The only thing that got the ball rolling here was the parents of some of the kids alerting google.

<comment><USER10> I got the impression that SRE basically have low level access to the storage stack. So wouldn't be subject to most of the normal application level logging that I would assume would red flag this behaviour pretty fast.

The only way to get around this is to have someone audit _all_ their actions constantly, which you need someone equally or more familiar with the systems they are working with.

I think that is pretty impossible to implement that level of overview with humans, the best way to go normally is the 'buddy system' so no one can access a system unless they have a 'buddy' with them. Like the military do in nuclear weapon silos.

<comment><USER9> Access to the low level storage stack would not allow you to query with so much detail and would likely not have an interface that would allow you to modify user settings at will. So he must have used some higher level tools.

<comment><USER11> Well it depends.

For example if an application uses Bigtable, then the key + column names often gives a lot of information about what data is stored there, which if somebody had access to some basic application data they might be able to get at somebodies specific data.

However as you might expect there are many safeguards in place, including ensuring every action is fully and securely authenticated so even low level SREs cannot read application data without a paper trail. This story is pretty surprising to me, and if true this guy is an idiot.

</comment></comment></comment></comment><comment><USER12> This is pretty serious and the fact it's turned into a story is one of the more damaging things you could expect to see about Google w.r.t. privacy. SREs are indeed very privileged and in many cases have carte blanche on their associated products. It's saddening one of them used his rights for nefarious purposes and broke some of the trust around Google's handling of personal data. I hope this leads to better auditing at least internally - seems like something that better transparency of access would have brought to light earlier.

<comment><USER13> While it is no guarantee of any change I like that they are not attempting to sweep this under the rug. There are a lot of companies where people have access to a lot of sensitive data. All you can do is screen the employees, limit their access where possible and audit their use of the security.

But then someone needs to audit the auditors. Just before I started here we used to have an employee who would look in the Oracle database used by Lawson to check payroll data. Nobody knew for a long time since he was the UNIX admin and DBA.

<comment><USER9> I don't know where 'here' is but you might want to edit that comment.

</comment></comment></comment><comment><USER14> I'm not a big fan of Gawker, but why not link to the original story instead of the meta-story?

<http://gawker.com/5637234/>

<comment><USER15> Because HN auto-banned it: <http://news.ycombinator.com/item?id=1692807>

<comment><USER16> That link just goes to a empty HN page

<comment><USER15> Turn on showdead.

</comment></comment></comment></comment><comment><USER17> I think google manned up well on this one. They will always have this problem. At least it seems they have less (that we know off) incidents than the government does. It's pretty incredible how many stories of government employees snooping (even selling it to organize crime) information stored in their databases.

<comment><USER9> That was my first take as well, but after reading up a bit on it it seems that they tried to make it go away by not charging him, when if you look at the severity of this case they had every reason to.

So they tried to sweep it under the rug by just letting the guy go.

If an employee of mine had ever snooped on end-user data and would have used that data in order to get real-world effects in the lives of those users I'm fairly sure I would have registered a complaint with law enforcement.

Google has their 'image' to be aware of, but in this case just letting the guy go may not be the best way to preserve that image.

<comment><USER18> Not that I have any information, but it could be that the parties affected did not want to pursue legal action. All we know about the story is a quote from Google and a speculative article from Gawker.

</comment></comment></comment><comment><USER19> this isn't that surprising. this stuff happens all the time at any company that has that many employees. a person i know who is a software developer at facebook told me that everyone there looks at people's private stuff and reads people's private messages when they want to and you just have to be discrete about it so that no one (i.e. users) notices.

<comment><USER20> I can tell you that it does NOT typically happen at Google. If you so much as joke about this stuff people will give you negative reactions. I was genuinely shocked to read about this today as I never would have expected any Google employee to be so unethical.

If what you say about the practices at Facebook is even remotely true then it is disgusting and shameful behaviour.

</comment></comment><comment><USER21> "For evil to flourish, all that is needed is for good people to do nothing." -- Edmund Burke.

Google's mere dismissal of the guy comes across as pretty evil. According to the article, there was a previous instance of malfeasance. If the bad PR behind all these privacy breaches were taken more seriously, Google would probably have to clean up their act and users would benefit as a result.

<comment><USER22> Wait, are you saying that we should be reacting to the PR (we didn't, he was let go some time ago) or to the act? I would always rather we react appropriately to the act. (disclaimer, work at google, blah blah blah)

</comment></comment><comment><USER23> I'm impressed with how transparent Google was with handling the issue. Unfortunately, things like this can and will occasionally happen. You can either put up your own Postfix server if you do not like it - or you can thank Google for continuing to provide such a kick ass free service.

As for David Barksdale, good luck to you, you will need it.

</comment><comment><USER24> I'm a lot more concerned about the data centers full of government employees wiretapping innocent people for no apparent reason. A fair bit came about concerning this a year or two ago, with ex-employees stating that the system was routinely abused for amusement. What's up with that these days?

</comment><comment><USER25> Maybe Google should add more questions related to ethics in their rigorous interview process.

</comment><comment><USER26> Just to keep this into perspective, we are reading about this because it is Google. But _every_ system and _every_ relay through which your email passes is a point where somebody with less then well-meaning intentions can read your email. We may be able to somewhat rely on Google to enforce some privacy policy, given publicity pressures, but some danger lies in all the carriers between point A and point B.

It is a shame that PGP only took off in the hardcore user community. If it was made insanely accessible to users -- maybe even transparent -- maybe we could have a better assumption of privacy for our communications (as well as a potential reduction in spam?).

</comment><comment><USER27> Still kind of alarming, I mean I do personally know some google employees and none would even remotely consider doing anything like this for both philosophical and practical reasons. Either way it's kind of scary that some douche fucker "quality assurance" dweeb had enough access to do this kind of thing.

I think we ought to have some kind of equivalent HIPPA act for ALL data personally identifiable to us, not just in medical contexts. That'd put the fire under googles ass enough to take our privacy seriously. Fuck Eric Schmidt and his "change your name at 18" bullshit. We know who that fucker is right now.

<comment><USER28> Did you ever see the full quote of the "change your name" stuff?

> Mr. Schmidt is surely right, though, that the questions go far beyond > Google. "I don't believe society understands what happens when everything is > available, knowable and recorded by everyone all the time," he says. He > predicts, apparently seriously, that every young person one day will be > entitled automatically to change his or her name on reaching adulthood in > order to disown youthful hijinks stored on their friends' social media > sites.

Which makes sense to me. Hell, I wish I could delete some videos and/or photos of me on various sites.

Lately Schmidt has been making statements like this though; they are reasonable when complete, but some reporters snip out five words (or, just paraphrase or interpret) and create a news storm. CEOs are supposed to be good at avoiding that sort of thing.

> equivalent HIPPA act for ALL data personally identifiable

We ought to start with getting the same level of laws for voip, IM, and email that phone and mail have. "All PII" is too vague, but those seem like a slam dunk.

</comment></comment><comment><USER29> Are GV calls all recorded? Is it there somewhere in the TOS? Even if its there, the consent of the other party is required to record calls. Otherwise its a offense. Right?

</comment><comment><AUTHOR> TC followup - [http://techcrunch.com/2010/09/14/google-engineer-fired- secur...](http://techcrunch.com/2010/09/14/google-engineer-fired-security/)

</comment><comment><USER30> I love that this is on the front page at the same time as Don Dodge's blog article about what an amazing job google does at hiring people: [http://dondodge.typepad.com/the_next_big_thing/2010/09/how-t...](http://dondodge.typepad.com/the_next_big_thing/2010/09/how- to-get-a-job-at-google-interview-questions-hiring-process.html)

<comment><USER22> You hire 20k people over 10 years and make not one mistake? Iknow you are being snarky, but there is no perfect hiring process, no matter what you measure.

</comment></comment><comment><USER31> Probably going way off deep end here... Sometimes I wonder if someone in the process shouldn't be licensed by the state in the interest of protecting the interests of the public. Just like doctors, lawyers and engineers.

That way, if something goes horribly wrong, someone's ass is more on the line than them just losing their paycheck.

<comment><USER32> As someone who formally worked in an engineering profession that required state licensing and now working doing the same job Mr. Barksdale did (not for Google, though), I can't see any sort of licensing helping with this sort of problem.

And I think at this point Mr. Barksdale ass is pretty much screwed -- it's unlikely he'll ever get a job doing this sort of work again.

It's a tricky problem. I know to do my job I need root access to everything. I guess at Google scale you could compartmentalize so the same person doesn't have free access across services.

But at some point you just gotta trust your people.

OTOH, perhaps I just don't understand -- what this fellow did is so over the top it's difficult for me to understand _why_ he would do such a thing. It's wrong on so many levels -- it's just not something I can comprehend.

<comment><USER33> My read on it was that he's a typical Aspergian nerd (of which there are several at Google), and it never occurred to him that what he was doing was not-okay. A lot in the story seems to support that. Why else is he hanging out with high schoolers - who don't even like him? Why does he feel the need to brag about his position at Google and the power it gives him?

Some people are born knowing all the rules to social interaction. But others have to learn them through painful trial and error. A lot of us got that out of the way in middle school, high school, and college, before we were given the responsibility to do anything truly damaging to ourselves and others. Maybe he just had the bad luck to not seriously screw up until he's at an age where everyone will blacklist him for it.

</comment></comment></comment><comment><USER27> This is a really big deal guys, it means nothing at all how comfy we feel knowing google peeps personally. The fact is there is no regulation or oversight dictating how seriously google needs to take our privacy other than random - easily ignored - blips like this. We need government intervention/oversight to make this stuff go away. The gov is already there unofficially anyway, let's not kid ourselves about that. Google gave that little piece away years ago. No us company with that much personal data would be allowed to exist otherwise. I would know, did gigs at bellatlantic long before "it" happened and uncle sam was and always has been there just the same. More about what they're allowed to officially charge you with in court - don't think they couldn't know either way at some level..though probably what they were doing really was in our national best interest. Not judging, just saying..we need offiial public oversight or be left at the mercy of what the corporation decides to do with our data. The same data that provides the overwhelming majority of revenue via advertisers. It's just sick is all.

</comment><comment><USER34> No worries. I don't personally know anyone who works for Google, so I guess I'm safe.

However, I do know people who work at a local ISP, and I'm sure as hell not passing my email through those servers.

<comment><USER8> If you hang out here long enough, you will likely get to know people who work at Google. (Like me.)

</comment></comment><comment><USER35> I'm amazed, positively. I wouldn't have thought they would be taking the users' privacy so seriously.

</comment><comment><USER36> I'm surprised all of Googles interviewing tricks didn't catch this.

</comment><comment><USER37> Hard call. They offer great free services and have changed the landscape of email, phone, and document communication. Yet they are one entity with all the information of DeJa News, Keyhole Maps, YouTube, DoubleClick, GrandCentral, Gizmo5, DocVerse, and their own email and app offerings. (see <http://en.wikipedia.org/wiki/List_of_acquisitions_by_Google>)

So yes, it is refreshing to see transparency of "Engineer fired for snooping where they shouldnt". But we keep using them as a service, so it's a hard problem to combat. After all, the price is right. Just costs your privacy.

<comment><USER38> While I enjoy bashing big corporations as the next guy, this isn't really a Google problem.

If you're on the internet, your information will always be available to someone. On the internets, as in real life, this power can be abused.

Appreciate the fact that they're open about it.

<comment><USER37> Trust me. I'm not bashing.

I have a blackberry hooked up to Google Voice and Mail servers. They know my name, address, all my phone numbers, all my emails, my contact lists, frequency I receive calls on my Google number, text transcription of voicemails. They also can potentially record every call I receive and make with GV.

Considering the benefit I get from _just Mail and GV_ , the datamining is a cost I'm willing to make. I also know if my phone is lost, I dont lose my data. And I can back it up elsewhere.

And I am somewhat happily shocked that they came such forthright that they "fired him for snooping". Most places will only say "They no longer work for the company".

</comment></comment></comment><comment><USER39> So this genius violated policy, and then bragged about it to his victim / the person who have the most reason to report him?

He's totally dumb.

</comment><comment><USER40> Wow...it appears Daniel Faraday left the island and took up programming...</comment>


A complete and detailed HTML reference - <AUTHOR> http://reference.sitepoint.com/html

<comment><AUTHOR> This has already given me some interesting ideas for utilising microformats into some HTML I am working on.

The presentation style of this resource is very chatty and gives lots of background to go with the data. Quite a contrast to the dry lists of tags that one normally comes across.</comment>


Ask HN: How Should I Produce and Sell a Food Product I Created? - <AUTHOR>

I've created a dessert that I want to mass-produce and sell to restaurants. I'm capable of producing my dessert on a small scale, but I don't think that I could make it in quantity without the help of a food manufacturer. I have a nearby factory in mind, but I don't want to approach them in the wrong way. I'm afraid that they will either ignore me or steal my idea. Any advice on how to approach a food manufacturer?<p>Instead of going straight to a manufacturer, I could show my prototype to local restaurants before I have a supply in place. However, I'm hesitant to try this because the product is relatively easy to reproduce. They may decide that they'd rather not wait on me to get a supply established, and produce the product on their own. Any advice on how to approach a restaurant? <comment><USER2> If the product is easily reproducible then perhaps you should consider going for the premium end of the market - retail that "home made" image even if you have to locate some premises and take on an employee or two to produce the quantities involved.

Branding may be important here - you need to establish an image for the product and then sell that. You will also need to deliver the product to your trial (hopefully later paying) customers in a format that fits in with their processes. So we are perhaps talking packaging of some sort here - at least for hygiene and probably for safe (perhaps stackable) storage.

Try looking for a nearby packaging manufacturer (not too large perhaps turning over less that $10M) with experience in the food market and ideally the catering market if that is where you think your product niche is. They will know a lot about how to manage their side of the business but will also have lots of contacts that could be invaluable to you in the supply and processing areas. They would be less likely to "rip off" your idea and could help a lot in bringing your product to market.

</comment><comment><USER3> Foodzie.com</comment>


A Better Way to Store Password Hashes? - <AUTHOR> http://www.opine.me/a-better-way-to-store-password-hashes/ <comment><USER2> Or just use bcrypt/scrypt/PBKDF2 in the typical manner. You're much more likely to screw yourself by mis-implementing this than you are to actually gain any real security benefit from it.

</comment><comment><USER3> This won't make an appreciable difference if your entire db is captured by the attacker (ala LinkedIn). You are just asking them to buy a box (rent a virtual server) with more RAM because the equals operation just became memory intensive. A machine with 128GB of RAM will still give a near-constant result to "does my test hash equal the user's password?"

"Just add more fake hashes", you say. To get around the above, you have to use billions upon billions of fake hashes. The database abuse will eventually catch up to you.

This is trying to accomplish what bcrypt and scrypt do using tunable parameters, which is force the attacker to spend significantly more to break passwords than it costs you to test passwords (because they are doing it billions of times, you are doing it once). Personally, I trust the math more.

<comment><AUTHOR> This is absolutely only to be used with bcrypt or scrypt, not instead of.

Facebook has 100PB of data, but all the password salts and hashes for their 800m active users fits on a single _USB stick_. One maligned employee and that data can walk right out the door.

The theft of all your users' passwords should make one heck of a racket on its way out of your data center. A thief should need the equivalent of a 747 to fly them out of there.

With this technique, Facebook could fairly easily make their salts and hashes fill 1PB of drives. You're not sneaking out of the data center with that tucked in your sock!

</comment></comment><comment><USER4> _The problem is, even with the salted hash, it's still too easy for an attacker to run dictionary attacks if they are able to retrieve a single user's salt and hash. When your attacker can do 1 billion SHA1 hashes/second with cheap hardware, even slowing it down 10,000 times and they're still cracking a lot of your users' passwords._

False. If you use Colin Percival's _scrypt_ to hash your passwords, then it's impossible for an attacker to crack them via brute force.

See previous discussion: <http://news.ycombinator.com/item?id=4076197>

<comment><USER5> It's certainly not impossible. scrypt provides reasonable defense against using cheap highly parallel approaches to brute force, but still can obviously be cracked by brute force.

For passwords, current typical attacker does not care about cracking all of them, but cares about finding some (mostly weak) passwords that he can try with other services used by same user.

<comment><USER2> Ultimately, OP's strategy is just increasing the cost of brute forcing. Why not use the cost increasing features built into the hashing algorithms themselves?

<comment><AUTHOR> Current algorithms allow you to increase cost in terms of CPU and RAM only. I want to increase cost on as many axis as possible, in this case, by requiring you to steal 1TB of mostly meaningless data, and not just 100 odd bytes.

[Edit] sillysaurus - It's a great image, but a little hard to parse since it doesn't actually show you the bits of entropy for each choice. If they did show a column for 40.5bits (average strength of a user's password) you would see the result is a lot closer to $150 for 'scrypt 64ms' than it is to the very sexy looking $4.8m.

Of course the technique could work even better with scrypt behind it (find/replace 20 bytes with 32 bytes).

<comment><USER6> It's worse than the average strength would suggest, too. You can't do an arithmetic average and get a meaningful figure because cracking difficulty doubles with every bit.

Say passwords were distributed evenly at 35, 40.5 and 46 bits. You may have a lot of difficulty cracking the 46-bit passwords, but the 35-bit ones will be easy. Now, you can't tell which users have easy passwords, but it's easy enough to try the "top 10,000 passwords" (from previous dumps) on all of the hashes you get and see if any match.

Without the scheme outlined in TFA _many_ users' passwords can be compromised this way. At 64ms each you can run those top 10,000 passwords on each user in less than 11 minutes, and you're almost guaranteed to get some hits. With this new technique, though, you _won't_ , because you'll be lucky to even pick a "real user" in the first place.

EDIT: Of course, if your system is going to remain at all practical to use you can probably filter out the fake passwords with a simple join. You won't have user-data for all of your fake users, and you don't want the username space taken up by trillions of realistic-sounding dummy names preventing bona fide users from registering.

<comment><USER7> You can't do a join because the hash table contains only hashes - nothing to relate them back to the user record.

This idea uncouples the password from the username and salt, which seems a good idea. But assuming you have access to the database, the additional work required is an indexed lookup instead of a simple equality - not actually a huge deal.

Having said that, when it comes to security I'll defer every time to someone with real chops in this area. Wake me up when Bruce Schneier comments on this.

</comment></comment></comment></comment></comment></comment><comment><USER8> Does it really matter that the hacker doesn't know which hash belongs to the user? He will still be able to do a dictionary attack using the same method you use to login.

Wouldn't this just make dictionary attacks easier? Now the hacker doesn't have to find one exact password but has the option to match any of his dictionary passwords to any of the password hashes.

I know that there are hardly any collisions and that in practise this wouldn't really change a thing. But in theory the dictionary attack would be faster this way.

<comment><USER9> 1\. The point of hashing passwords is to protect the password itself (the plaintext), so that users who use the same password over and over again (which is most of them) don't see all their accounts opened if one of the services they use has a security breach.

2\. Collisions are not actually very likely (understatemeeeent)

3\. > He will still be able to do a dictionary attack using the same method you use to login.

Sure, but that's not the point. The point is that validating a hash now requires a lookup into terabytes of data, meaning it's much harder to use ASICs or GPUs to brute-force the site, and the validation may even require hitting disk which is _extremely_ expensive compared to even expensive hashings.

4\. It also makes _retrieving_ the data that much harder: a users table is not usually big and noticeable (especially just 3 columns thereof), a terabyte+ of data going out might show up on the network stats.

Note that I'm no cryptographer and do not recommend TFA's scheme as I can't judge one way or the other, but your objections don't hold as far as I can see.

Side-note (and weakness) for 4: on the other hand the retrieval is trivially shardable and parallelizable, so at the end of the day you probably don't gain much: the data from the GPU/ASIC hash-computer is fed into a sharded db server for matching against the hash data, it will have a cost impact but depending on the cost of the hashing function itself it may not even increase the overall operation time.

</comment></comment><comment><USER10> Doesn't this add a new vulnerability? If I can see the salt for a user, I can easily add a new password for that user _without anyone possibly being aware of it until it is used_ by just adding the hash of the desired password with the existing salt to the database.

<comment><USER11> That's true: in a classic system, the original user will notice its password had been overriden. With 'security through obesity' the original user AND the hacker will be able to login (each using their own password).

</comment></comment><comment><USER12> Seems like it'd paint you into a bit of a corner if you ever needed to change anything about your password hashing.

Say some mythical unbreakable hash algorithm comes along that's O(1) and you decide you want to move to it, you're forever going to have to drag along these terabytes of junk hashes as you're entire userbase wont log in (giving you the opertunity to change how their password is stored) and since you can't tell the noise from the signal you'll forever have that enormous table of hashes from that time you tried to be extra clever.

I'll leave crypto to the experts :)

</comment><comment><USER13> This sounds interesting. But, in implementing this, what's the purpose of storing password hashes in your own database? Wouldn't it be safer (and maybe even faster) for a centralized service to handle checking the existence of password hashes and storing them?

Compromising this central database would be meaningless because it would only store password hashes. If an intruder accessed it, they'd just have billions of long strings of random characters -- they wouldn't know where it came from/who uses it.

I think the biggest downside would be that the larger number of password hashes, the more likely duplicates exist. The answer to that, I think, is more randomness. But, I don't know how soon/if that would be a problem.

Another potential downside is performance. Would making a request to this other server make logging in slower? I think the answer to this question depends on the implementation, but there's a guranteed latency of another server to contact before logging in/registering. Beyond that, I think, would be getting too much into the implementation details.

Note -- I know very little about cryptography, but I'd love to learn more.

</comment><comment><USER14> I am skeptical that this method adds any protection to a brute force attack relative to a standard implementation of PBKDF2 hashes stored with the users.

With proper salts, we have no advantage cracking a password in a database of 10 users or 10 million users. LinkedIn didn't have any salts.

The effectiveness of brute forcing a password is determined entirely by how many passwords they can test for a particular user (because they are salted) in a given period of time. Sure you can add tens of gigabytes of extra data that they have to search through, but your system has to search through it too so it's no different than adding extra iterations to PBKDF2.

<comment><AUTHOR> It's a question of sizing up what resources the attacker has, versus what they will need to succeed in an attack.

We want to make password cracking extremely difficult. It's a problem a big site should want to throw some money at.

Today, we make it hard by requiring lots of CPU. Another commenter said 'scrypt' -- yes, we want to make it hard by requiring lots of RAM too.

Here's another way to make it hard -- now you'll need to make a clean getaway with multiple TBs of data off my server too, just to hopefully steal ONE user's password.

There is a benefit here, I think.

<comment><USER14> Ok, requiring the attacker to download several terabytes could be an interesting advantage. Could we also achieve that by inserting billions of fake users in a traditional [user, salt, hash] setup?

<comment><USER15> You could, but I don't really see any difference between this and just slapping many tb of unrelated data in the database - the smart attacker will realise that a bunch of accounts are fake and just join to a table that holds only data for real users before extracting the info.

That's part of the elegance (well, it's something other than elegant because it uses a whole mass of data) of the original solution - all of the data could be significant in checking a single password so none can be discarded.

<comment><AUTHOR> As the OP, I'd say it's as elegant as securing your bike by locking a cinder block to it! ;-)

</comment></comment></comment></comment></comment><comment><USER16> Implemented correctly (with using e.g. scrypt as the hashing component, and making sure the hashes are large enough so that the chances are neglegible of an attacker finding a match to a _different_ hash than that was originally generated from the users password), this scheme would be no less secure than the traditional way of storing one scrypt hash per user.

The only effective difference would be that the entire database would become a single unit instead of a collection of separate hashes. Both an attacker and your webapp need to carry this extra weight of a monolithic blob of un- dividable data. It probably won't really slow down an attacker trying to brute force it if he has the data, but it may be more difficult to get the data in the first place.

But if an attacker has access to, say 10% of the hashes, he'll still be able to brute force 10% of the user accounts with weak passwords.

A different way to get a similar result of requiring a huge amount of data to be able to start cracking, would be to treat the database like a huge bloom filter: treat the database as a huge bit array of (say) a petabyte, hash the user's password with a hundred different hash functions (but with scrypt-like slowness), and use those 100 hashes as 100 indexes into the array to set the corresponding 100 bits. To verify a password, create those same 100 hashes and check if all 100 bits are set. Now, if an attacker has access to a part of the database, he won't be able to determine with certainty of any of his guesses at the user's passwords are correct.

Yet a third way to accomplish the same goal: pre-generate a petabyte of random data. To hash a user's password, apply a standard scrypt, then based on the resulting hash, generate a 100 pseudorandom offsets into the petabyte of data. At each of those 100 offsets, read a few (say, 16) bytes from our petabyte of random data, and finally store a hash of (scrypt_result + huge_data[offset1] + huge_data[offset2] + ... + huge_data[offset100]). You'd still have one hash per user, but to check a hash you also need access to a huge block of random data. The block of data functions in a way as an additional system-wide salt.

Anyway, there are more ways to get to a similar result as the OP's proposal. I'm not sure if it buys any additional security or if it's just more of a hassle for the webapp implementing this, but at least it's fun to think about.

</comment><comment><USER17> I think you need to make sure that each user has a unique salt.

If you happen to assign me the same salt as another user then either my or their password will unlock either account and the attacker only needs to guess the weaker of the passwords.

<comment><AUTHOR> Absolutely correct. A 'salt' by definition, is always random.

For example, you could use a 32-byte salt with scrypt and you would get back a 32-byte hash. Both are equally unlikely to ever collide (see numbers in the article) even with trillions of entries in the table.

<comment><USER17> With this scheme random isn't quite enough though, it needs to be unique as well doesn't it?

<comment><USER18> Chances of generating two random 32-byte strings that collide are so tiny that you can as well say that they are unique.

<comment><USER19> Remember that assumption is the mother of all fuck-ups, although in this case the risk as you say is minimal.

<comment><USER10> Making an assumption that will fail approximately one time in the entire history of the universe is safe.

</comment></comment></comment></comment></comment></comment><comment><USER20> One thing that stands out is, it seems like you can never purge this table. If it ever grows so large that it becomes a concern, you'd need to force your users to validate in another way and set a new pw using a fresh db

</comment><comment><USER21> And what about using a pepper in addition to a salt? Then a potential attacker requires access to application code as well as the database tables.

I can also imagine some kind of DDOS against the database using the linked system.

</comment><comment><USER22> Wouldn't this setup mean that I can hack into your system with almost any password? As there is no direct connection AND you fill up with dummy hashes - doesn't that effectively mean you drive up the chances of a hack? The more fake hashes, the higher the probability that any random password I brute force may result in a match against the set of hashes. And if that happens - boom, I am in. Or am I missing something?

<comment><AUTHOR> Definitely not. The back-end takes a user's password and hashes it with that user's specific salt. Then the result must be in the table. Another user's password will not work.

What you are worried about is a result existing in the table, even with the wrong password. That can only happen if you have a hash collision. The article on collisions I cited (<http://preshing.com/20110504/hash-collision- probabilities>) says that even with 171 trillion hashes already IN the database, the likelihood of a collision is still only 1 in 10^18. And that's using SHA1 -- SHA-256 would be even better.

[Edit] Ooops, I forgot a zero. It's actually 1,710 trillion hashes in the database to make the risk of collision 1 in 10^18. OK, that's 1.71 quadrillion.

<comment><USER22> Ah OK. So effectively the salt becomes the foreign key ;-)

<comment><USER23> Actually not a bad idea. You could also hash the salt and use it everywhere instead of the user's ID - anonymize the user from their own data. (If you used the password hash, you would just have to remember to update it everywhere on password changes - and of course use a hash of the hash so you didn't give away which hash was used.)

For instance, let's say I was UserID 123 which had a FK to a table of bookmarks or history and normally it would be easy to link that user to personable data such as Cancer, Job searches, Pr0n, etc. Now instead, you have a lot of these bookmarks pointing to a hash that was used in the initial user login and not directly linked in the database.

Typically in highly sensitive databases you hash out a new "ID" entirely and reference that. Then you provide a different service and database entirely that correlates two different identities when you need identification. This is similar to how PCI requirements for credit cards store the actual numbers elsewhere and use a token against the system for consumption.

</comment></comment></comment></comment><comment> bad-juice NO! This is a bad idea:

"When a user logs in, you retrieve the salt for the given user, re-compute the hash as you normally would, and simply check if the resulting value EXISTS in the Hashes table. If it does, you consider the login as successful."

This will cause false positives. Let's say that of the trillions of hashes, one is the one we want... But what if one brute forces the system? What if one of the brute attempts matches ANY of those trillions? Bam. Access.

This is a very very bad idea.

Do not roll your own security unless you know what the F __& #@ you're doing. You are trading a compromised security issue (your attacker already has access enough to get the hashes/users) for a uncompromised security issue (your attacker does not have access to the hashes/users, and is just trying to get in via brute force).

You are making it easier for the non-secure access attacker by making it harder on the secure access hacker. You are making the most common threat bigger to make the least common threat smaller.

Let me explain it using the pigeonhole principle.

Say you have 2 pigeons (passwords) and 1 million pigeon-holes (hashes aka possible passwords). Assuming all the pigeons are in a hole, and you reach into a random hole, what is the chances of pulling out a pigeon (password/hash collision)?

Now, let's say you have one hundred thousand pigeons (What OP is suggesting) and the same million holes... What are your chances of pulling a pigeon out of a random hole this time?

I wish I could use font-size 1000px right now.

Do not do this. Do not do this. This is a compromised system, right off the bat. If you are securing people's private data or possessions in this manner, you are doing them harm.

As more users sign up, the chances of brute forcing actually increases (more hashes to possibly match!). Let me repeat that in a different way: EACH USER MAKES THE SYSTEM LESS SECURE.

Besides all that, let's say you have to do an EXISTS check on a million records. That means you will check each one until you find a match. That is a linear complexity, that is O(n), unless you index the column, which is expensive. Could take a while, depending, but most certainly will take longer than searching for something with a known key that is indexed efficiently (being an index on a primary key), which should give you something like O(log n) which is much faster.

I don't mean to be an ass, but please downvote this so that there is less chance of people implementing this.

OP; you are suggesting a very harmful idea. Remove it if you have any amount of goodwill towards the community.

I work in web security, and used to work for a credit card merchant processor. At one point, I had access to and had to secure millions of accounts with authorization information for their credit cards; this being information one could use to empty a bank, no questions asked.

I Really Know what I'm talking about. THIS IS A BAD IDEA.

<comment><USER24> Such a long reply repeating the same thing is very obnoxious. Don't do it. If I could downvote you I would.

Do you really know what you're talking about, huh? Your pigeon-hole example is pretty wrong because you can't use intuition (with completely wrong numbers!) to judge, you use math. Let's say there's a trillion pigeons and the hash we're using is 256 bits. That 2^256 ~ 10^77. Divide that by a trillion and you still have 10^65. Vastly more than enough to be secure all the while solving two problems. First that with a specific user's password one can often access other services. Two, and most importantly, that the password database blows up and isn't feasible to steal any more, either over internet or in real life.

</comment></comment><comment><USER25> This would increase the complexity of the hash verification by log2(N) times, where N is the number of user records. So even if you do have a billion hashes, you only slowed the attackers 30 times. You might as well increase the BCRYPT complexity and skip this scheme.

<comment><AUTHOR> This should be used with scrypt or bcrypt set to the highest difficulty your application can support.

The point is to increase difficulty of targeting an individual user, and increase difficulty of stealing the data in the first place. This is separate and distinct protection from what scrypt/bcrypt gives you.

[Edit] In a typical GPU accelerated brute force attack, the target hash and salt are both known as fixed 20 or 32-byte values, and you iterate through candidate passwords until you find a match.

In the proposed technique, the target hash is NOT known! Instead, what you do know is a salt and a list of a few billion hashes, ONE of which can be obtained by combining the salt with some unknown password. This is a very different equation, and I believe, much harder to solve, since your target value can't just be kept in a register or L1 cache for comparison purposes.

<comment><USER25> Actually, I was wrong about O(log(N)), the lookup time is O(1), you just have to put all known hashes in a map structure, or even better, a rainbow hash.

So your technique only adds some constant lookup time.

Instead of

        if (hash == target_hash) ...

you will do

        if (map[hash]) ....

Sorry, I think you are wrong.

<comment><USER26> eh, this is amortized O(1) and you are almost guaranteed slow lookups for a large number of requests.

don't confuse true O(1) with amortized ;)</comment></comment></comment></comment>