Uber sets self-driving battle at permission, not existence - <AUTHOR> https://techcrunch.com/2016/12/20/pay-no-attention-to-the-car-behind-the-curtain/ <comment><USER3> I genuinely do not get Uber's strategy here. Even once self-driving cars are mature, they'll occasionally screw up and sometimes kill someone. And Uber's cars are so incredibly far from mature that operating without legal cover is... just insane. If they kill and hit someone, Kalanick is easily portrayed as a ready-made movie villain. Wantonly ignoring state and local laws in the hopes of getting ahead of the pack, sacrificing the life of cute little toddler Adam to the altar of Mammon?

And it's really not just portrayed: Uber'll deserve any and all punishment thrown at them for this, up to and possibly including the shut down of the company and criminal charges for the people who did this. And Uber'll be setting the cause of self-driving cars back years, maybe even a decade.

This is all incredibly obvious too, and I don't think Uber folks are idiots. Maybe they're getting desperate, and they're willing to eat the risk of the company being destroyed because their business strategy for survival is sensitive to getting to production-ready self-driving cars a year earlier than they would have otherwise?

<comment><USER4> Uber's is laying the groundwork to make the legal case that Tesla owners using autopilot are in fact 'testers', presumably in hopes of tangling Tesla up.

'Levandowski compared Uber's technology to Tesla's autopilot feature, saying: "It's hard to understand why the DMV would seek to require self-driving Ubers to get permits when it accepts that Tesla's autopilot technology does not need them."

[https://www.theguardian.com/technology/2016/dec/16/uber- defi...](https://www.theguardian.com/technology/2016/dec/16/uber-defies- california-self-driving-cars-san-francisco)

<comment><USER3> That's interesting, if it's actually the case. It seems a bit of a stretch to me--Uber is still opening itself up to existential risk--but if by doing so it can plausibly kneecap Tesla and if it views Tesla similarly as an existential risk, this move might make sense.

ETA: That is, from a business perspective. The fact that you might kill a couple people in the meantime is kind of a deal breaker from a moral point of view.

<comment><USER5> How many people does delaying the progress of self driving cars kill?

<comment><USER3> Interesting point. Let's guesstimate it. I'll focus on the USA.

Let's assume that after the full transition, 0 people will die from automotive accidents. This isn't the case, but it's close enough. Naively, that would save roughly around 30k lives a year: in other words, every single day self- driving cars are delayed kills a bit under 100 people. The dynamics of the transition don't matter too much, assuming everything is simply shifted forward a year: you just move one year from the totally untransitioned state to the totally transitioned state.

That's huge. Anyone who does something that delays the transition one day is basically pretty much committing the Pulse night club shooting and the Sandy Hook shooting.

Now, another question: if a self-driving Uber slams into a group of children crossing the street, how much do you anticipate that to delay the transition to self-driving cars?

There's also a hidden assumption that getting inferior products on the road as quickly as possible is a necessary step in order to start iterating as quickly as possible. A day of clean room testing is worth some small fraction of a day of real world testing. I don't quite dispute that point, but just stating it explicitly.

<comment><USER6> Safety standards that delay the transition by a week might also save one person per day from being hit by a beta car during the transition period. You can't just tally deaths on one side and ignore the other.

</comment></comment></comment></comment></comment></comment><comment><USER7> Genius? If you hurt someone on the road by doing something explicitly illegal which you have been explicitly warned against doing, you are looking at massive financial liability to victims and potential involuntary manslaughter charges against executives.

TechCrunch's suggestion that this is the thin edge of a wedge to get to do self-driving without regulation is preposterous. There is no future reality in which the Department of Transportation does not strictly regulate self-driving vehicles.

<comment><USER8> It's about the public's perception as well though.

<comment><USER9> Although to me there's a big difference between "innovating" on bureaucracy and ignoring "public safety"

<comment><USER10> Yea the laws uber broke were mostly bad regulations that nobody cared about and ultimately didn't harm anyone (other than in a competition harms incumbents).

But beta testing their cars on real streets could lead to disaster. Even from a non-legal PR risk perspective, it's dicey.

If one of these things runs over a cute kid, the attempt to skirt the law will backfire. That said challenging the law isn't necessarily skirting the law, but that's how techcrunch is portraying it. I'm too lazy to read the docket of the case.

<comment><USER11> Like minimum wage laws. Right.

<comment><USER12> There they just followed the existing model of taxis.

</comment></comment></comment></comment></comment></comment><comment><USER11> Not really. The CA DMV can suspend or revoke a self-driving permit for bad driving, as with any other driver's license.

 _§ 227.36. Refusal, Suspension, Revocation of Manufacturer's Testing Permit_

 _The department may refuse an application for a Manufacturer's Testing Permit, or for the renewal of a Manufacturer's Testing Permit, and may suspend or revoke a Manufacturer's Testing Permit:_

 _(a) For a violation of Vehicle Code section 38750 or this Article._

 _(b) For any act or omission of the manufacturer or one of its agents, employees, contractors or designees which the department finds makes the conduct of autonomous vehicle testing on public roads by the manufacturer an unreasonable risk to the public._

It's pretty straightforward. This works just like regular bad driving enforcement. There are now two reports of Uber self-driving cars running red lights and complaints about bad turns through bike lanes, so DMV can reasonably deny a permit. Google doesn't seem to have those problems.

[1] [https://www.dmv.ca.gov/portal/wcm/connect/d48f347b-8815-458e...](https://www.dmv.ca.gov/portal/wcm/connect/d48f347b-8815-458e-9df2-5ded9f208e9e/adopted_txt.pdf?MOD=AJPERES&CONVERT_TO=url&CACHEID=d48f347b-8815-458e-9df2-5ded9f208e9e)

<comment><USER13> Exactly this.

A friend of mine is a reckless driver, who think of himself as a rally pilot. He often drives at twice the speed limit, passes other cars when there's a continuous line, etc. After a wedding dinner, (where he drunk more than enough) he announced he was driving home. I had to ask:

\- Are you sure you should be doing this?

\- Yeah, even with a glass or two (I counted a good half-dozen) I'm a better driver than 90% on the road anyway…

\- I mean, that might get points off your license. [He had mentioned losing some during the dinner.]

\- Nah, it's OK: I don't have a license anymore, so I have no points to lose. I'm smart like that, you see?

I agree with TechCrunch: Uber is smart like that too.

</comment></comment><comment><USER14> So Uber are on course to make a huge (multi-billion dollar) loss this year, and on top of that they choose a course of action which could lead to jail- time, might kill someone, and result in massive civil liability. They also make autonomous vehicles look like a half-baked kludge with no real place on the roads and might even cause some regulators to ban them indefinitely. Brilliant.

<comment><USER11> They're on course for having a car pulled over, the cop asks for their self- driving permit (SFPD probably has briefed their people on this by now), they don't have it, the driver is arrested and the car gets towed to the impound. Routine enforcement.

If it's an accident, it's much worse for Uber.

</comment></comment><comment><USER15> This is ridiculous analysis. If Uber loses (or wins) this DMV "permission" battle they don't magically win the "existence" battle. The state never forfeits its right to challenge whatever it wants to challenge, whenever it wants to challenge it. And if the state loses in court it can even change the law and fight again - no private entity has that power.

To the extent Uber is doing something clever, it probably has something to do with avoiding having to spend $150 for every entity or person that wants to buy a self-driving car and rent it out through Uber. It is certainly _not_ that they have found a brilliant way to sidestep a legal battle with regulators.

<comment><USER16> > And if the state loses in court it can even change the law and fight again - > no private entity has that power.

Sadly, not at all – Uber will just sue in some court of some trade deal, and find a way to get around that. Just like so many companies have done before.

</comment></comment><comment><USER17> This sort of behaviour by Uber seems to signal an internal desperation. High risk gambles are what you take when you are a scrapy startup with nothing much to lose, not a multi-billion dollar business.

<comment><USER18> Wall Street did this for decades. Don't underestimate the human factor.

<comment><USER17> ...and didn't that end well in 2008.

</comment></comment></comment><comment><USER19> Human drivers can feel relatively safe around other cars because of mutually assured destruction. You are both afraid of dying if you make a significant mistake.

Self-driving cars will never have this fear holding them back from making mistakes. They don't care if they die. How can you feel safe around that? You could argue there is actually an incentive to let them crash once in awhile, because the valuable real world data will be phoned home and used to improve the product for the small price of a human life.

Once corruption sets in down the road, cars with autopilot capabilities will simplify kidnapping and assassination. Simply activate the backdoor remote piloting feature and crash your target's car (or the Uber car they're a passenger in) into a tree at 70 mph, or lock the doors and drive to a pickup location to complete the kidnapping.

Driving in a traditional car wouldn't protect the target, because a group with ubiquitous optional remote control over self-driving cars could also force surrounding cars to enter kamikaze mode and ram the target off the road.

Governments will demand some kind of backdoor like this at some point. It's not a question of if, but when. At that point, we'll have to trust that they'll never abuse it (lol) and that no third parties will ever be able to hack it remotely.

Even if you think the government is your friend, the first worm using a remote code execution exploit that hops from car to car via Bluetooth and activates its payload on a specific date will be able to kill tens of millions of people.

<comment><USER20> I won't comment on the apocalypse scenarios you described, because the possibility is obviously there. But regarding the MAD scenario on roads, I believe with self-driving cars you're trading off ability to survive in _very_ rare cases (like split-second decision after reading the face of the driver about to crash into you) for having the usual accident causes (speeding, distracted driving) not happen.

My hope in the transition period is that the presence of self-driving cars on roads will finally force the drivers to start obeying traffic laws - <USER2> should pretty much eliminate the MAD consideration altogether.

</comment></comment><comment><USER21> I genuinely hope someone at their HQ has an explanation. This doesn't make sense on any level at all from my PoV, but i'm not valued at 50bn$.

I would love to see some super smart twist on this, incompetence and hubris becomes boring to watch fast.

</comment><comment><USER22> uber. i have nothing against improving these services, but doing it with such blatant disregard to the law.

if this was just some guy on the street, or even most businesses the authorities would come down on them like a ton of bricks... but its a silicon valley posterchild so we don't.

its so difficult to see and not feel anger about it. if i don't do my due diligence or act intelligently i feel uncomfortable like i'm taking a stupid risk... why don't they?

<comment><USER20> Maybe Uber is secretly in legislative pentesting business - working to probe just how much laws they can break and still get away with it.

</comment></comment><comment><USER23> Cycling and pedestrian advocates are speaking against self driving cars [1].

It's so much easier to fix software for "right hooks" then it is to fix human drivers, who drive terribly in SF.

[1] [https://www.theguardian.com/technology/2016/dec/19/uber- self...](https://www.theguardian.com/technology/2016/dec/19/uber-self-driving- cars-bike-lanes-safety-san-francisco)

</comment><comment><USER24> Every time Uber is mentioned, it blows my mind how many people care about the law at the expense of innovation.

According to google, 3,287 seem to die everyday on the road. I honestly don't see those numbers happening when humans are taken out of the equation.

I've asked this before, but will ask it again:

Why be apart of tech if you want to follow the rules?

<comment><USER6> The vast majority of Uber's activities have nothing to do with safety.

And the very basic laws around self-driving cars don't slow innovation in any way I can see. Not everything is a dichotomy.</comment></comment>


Ask HN: What do I need to learn to start an online magazine? - <AUTHOR>

I've decided to explore the idea of starting an online magazine.  I'd like to be able to run it myself.  Most of my experience is in scientific computing, but I'm familiar with HTML, CSS, Javascript, C and Python.  I'm working on learning more about databases (currently taking the Stanford Class2Go on databases http://class2go.stanford.edu/db/Winter2013)<p>What else would you recommend I look into? <comment><USER2> > What else would you recommend I look into?

Content. You've described skills that could be used to put together a Website, but there's no mention of your literary or journalistic abilities.

Nothing is easier than launching a Web-based magazine. Nothing is harder than filling it with fresh daily content so people visit again and again.

<comment><AUTHOR> I agree that content is key and I'm putting other resources into generating that content. I'm not trying to do anything big or amazing; rather I'm trying to create a place for my friends and I to exercise our creativity that's more than just a blog. I'm an economist and will be converting a lot of what I would put in my blog into essays and responses about current economic news. A good friend of mine is already doing something similar for travel, and has expressed interest in contributing. Same thing for sports. I have some friends who are chefs that are interested in writing about food, and others who brew their own beer.

Right now, I am (irrationally?) optimistic about content. This is as much about my friends and I creating something as it is a serious attempt at journalism or literature.

So, assuming that content is covered, would you expect the skills I mentioned to be sufficient for building and running a site?

<comment><USER3> After content, next thing to focus should be operation. For online magazine it should be editorials and technical.

I suggest going the wordpress route as the backend cms. It easy enough to beginner and fast enough for growing audition. Thus you need a person good on it to design and extend the functionality.

But still, good and enganging content always preceed technology. HN is a good example of that.

</comment></comment></comment><comment><USER4> Design.</comment>


Startup Idea: Shopify for SaaS companies - <AUTHOR> http://bestengagingcommunities.com/2012/07/19/startup-idea-shopify-for-saas-companies/

<comment><USER2> Most of the things you mention are already available: sign-up from Facebook/Twitter/etc and payments Stripe/Recurly/Paypal. The fact is that generally those things need to be customized for the specific needs of each product even more if you're not building a generic site, ie. a forum or an intranet. And then offering a sufficiently easy to use API to do rather complex things ends up "bounding" the ability to extend it. (Which is is what happens when people want to customize modules for popular CMSs like Wordpress.) Also there are also frameworks that take care of this Django/Rails.

</comment><comment><USER3> ..i suppose you haven't heard about rails yet.</comment>


An Extraordinarily Expensive Way to Fight ISIS - <AUTHOR> https://www.theatlantic.com/magazine/archive/2018/07/william-langewiesche-b-2-stealth-bomber/561719/?single_page=true <comment><USER2> The cost of a military operation is not in dollars, but in lives. How many dead soldiers are worth saving a few million dollars on bombs?

American doctrine is and always has been peace through _overwhelming firepower_. You don't want a "fair fight" in war. The objective is to obliterate the enemy through any means possible, and avoid harm at all costs.</comment>


A123 files for bankruptcy - <AUTHOR> http://blogs.wsj.com/corporate-intelligence/2012/10/17/batteries/

<comment><USER2> So, I actually know one of the executives (friend of a friend) at A123 and I've been hearing about the company since well before it went public. I guess these are my thoughts on the company.

Auto makers strung them along. A123's technology was cool, but ultimately no auto maker would allow itself to be beholden to a proprietary battery technology ahead of its time. Imagine you go with some new battery technology patented by company Y and create a massively successful vehicle. Next year, company Y asks for double and you're faced with Y taking your profits or having next year's model have a significantly reduced range. Companies simply can't offer that.

In A123's case, manufacturing had trouble. That needs to be clarified. When working in China, the trouble was that IP protection is poor and it's culturally normal to copy/steal other's technology. They had to split up manufacturing and create processes to make sure that their IP was safe. When looking to work with US automakers or the US government, they (and many unions) wanted manufacturing jobs in the US.

Ultimately, A123 was trying to create a premium product in a market where things are meant to be interchangeable. Imagine a company trying to sell "ultra-flour" or something. Even if it's provably better, it's not how the market operates. Auto makers were (and probably are) interested in their technology. However, it's hard to commit to proprietary battery tech. A123 always felt right on the verge of an agreement with Toyota or GM that never materialized. Toyota isn't going to single-source a component - it's against the way Toyota does business - and GM has probably learned from its past of doing the same.

I always thought that they should have focused on smaller items. A car is a major item and it's something that grabs headlines, but A123's cells could be used for other applications (and were: I think it was Black and Decker that was using A123's batteries in their high-end tools for a while). While cars are great, better batteries could be great for phones, laptops, and other applications where reducing battery life wouldn't be as terrible as reducing vehicle range - and, in fact, we've seen LTE phones that have sold very well with a fraction of the battery life of their predecessors.

EDIT: In a way, A123 was a bit like ARM. They were creating something new that could challenge incumbents and open up new opportunities. The smartphone revolution wouldn't have happened on x86 given the power draw. However, if ARM was the exclusive manufacturer of their design/instruction set, it might not have happened either. The fact that ARM licensed their IP gave companies a feeling of safety - one they never got from A123. For example, if Apple is unhappy with someone's yield on processors, delivery schedules, whatnot, they can get another fab to make their A6. If Apple were to be unhappy with A123's deliveries, they wouldn't have another place to get the same technology from. ARM's licensing meant that Motorola could use a TI processor in one phone and then evaluate whether TI was a good partner or whether they wanted to try Qualcomm for their next device - and processors from Qualcomm, Samsung, TI, nvidia, and others would all be generally interchangeable from the consumer's stand point. That wouldn't be true of substituting mass-market batteries for A123 batteries and with the world's supply of their battery technology controlled by them, that meant giving A123 a lot of leverage over you. That's where A123 had a different path from ARM and why I think a lot of companies wouldn't commit to using A123's technology - they'd be beholden to one company. If A123 licensed the technology, they might have become the ARM of batteries and seen others manufacture them while they focused on research and development. Maybe I'm completely off and it isn't a comparable situation.

<comment><USER3> Very compelling, thanks for posting this. A123 sounds like it will be an usefull case-study somewhere, in years to come.

 _I always thought that they should have focused on smaller items. A car is a major item and it's something that grabs headlines, but A123's cells could be used for other applications_

One interesting question, in hindsight, might be would they have survived/ succeeded at reduced scale? And what role valuation and politics had in force- feeding them into a make-it-or-break-it aspiration.

Hopefully some of their good stuff will remain available, in whatever form, however.

<comment><USER2> So, I'd argue that smaller batteries aren't smaller scale. A lot of people are chasing autos right now. However, that's not the majority of battery use. I think part of the issue is that your smartphone's battery is "good enough". By good enough, I mean that while people complain about battery life, it doesn't stop them from purchasing the devices. So, a smartphone that gets 2x battery life isn't the same draw. In fact, based on the Anandtech review of the iPhone 5, some phones get substantially greater use times when compared to other quite popular models.

By contrast, the 60-ish mile range of a Nissan Leaf just doesn't cut it in more ways than one (unlike a phone, it can't be easily charged in loads of places, unlike a phone that could charge 50-80% in an hour, the car really needs a third of a day, etc.). So, a better battery for a car might become game-changing while a better battery in a power tool or phone might just be nice or luxurious.

Still, there are a lot more applications for batteries in the non-auto world. Premium laptops could be sold with them or as aftermarket add-ons, phones, tools.

Not to beat a dead horse, but in hindsight it was quite clear that no established auto maker would allow themselves to be single sourced on a critical component - no responsible business could operate that way. To pursue the auto market would have required being the auto maker, selling out to one of the auto makers, or allowing the auto maker to multi-source your technology. And, in A123's defense, they did create their own plug-in Prius cars (google Hymotion), but Toyota didn't like it, it was an expensive add-on to an already expensive car ($10k I think), and took up a bunch of trunk space.

It's also possible that it would have been more successful in more niche areas. To talk about software for a moment, everyone wants to make Facebook, Google, Weebly, Reddit, etc. It's the kind of project that people consider cool. However, it means that a lot of smart people just ignore things that companies need (those enterprise-y things) as dull - and those enterprises often end up with poor tools in those areas. It's possible that A123 could have worked on delivery vehicles or other vehicle fleets.

Consumers are hard to please. If I want to go from Boston to New York, I want to be able to go with the best convenience. Cargo doesn't tend to give a crap if it's delayed half an hour. So, for UPS' local delivery trucks, batteries might work nicely. Batteries tend to better with frequent starts and stops than combustion engines. UPS could have battery swapping stations to remove one battery pack for a freshly charged battery pack in a way that might be hard for consumers. UPS could easily make the calculation that the cost savings could mitigate 15 minute delays.

I don't mean to say that it would work for UPS. However, when we look at things like LNG or full ethanol or other alternative fuels, they tend to be more widely used in fleets that can manage the infrastructure to handle them. However, those enterprise-y things aren't the things that grab headlines and change the world. You don't get the feeling of "everyone knows what I do and I'm having an impact on the world" from helping UPS to cut its fuel budget by 15%. You get that feeling from doing very public, very consumer things.

For example, by some estimates (US DOE), cars use about 40% more energy than passenger rail. So, everyone who likes green things wants more passenger rail. However, then we take a look at freight. Trucked freight uses over 1000% more fuel than freight rail. So, if one wants to reduce energy usage (and pollution) the most, moving freight from truck to rail is much more important than moving a passenger from car to rail. It's also more convenient since freight often doesn't mind waiting an hour or two for a transfer in the way that passengers want convenience. But freight rail is the behind-the-scenes logistics and doesn't have the same celebrity factor.

So, politically, we talk a lot about new passenger rail and how it's wonderful and green. However, consumers are hard to please - you have to really make sure that something works with changing consumer patterns, that it is convenient for their lives, etc. Enterprises can often be satisfied more easily. A consumer might get annoyed that a battery exchange station takes 10 minutes while a UPS driver is happy that they have a 10 minute break. A consumer doesn't want to wait a couple hours for a transfer while freight is generally happy to idle.

So, it's possible that even within the automotive sphere, going toward the enterprise side of things could work out better. It's not as cool, but it can also be a stepping stone to something wider.

</comment></comment></comment><comment><USER4> I don't understand this.

Whenever people talk about cutting the defense budget, people bring up DARPA and how much great research is funded through it. But then the same people decry federal subsidization of companies like this when they fail.

The whole point of federal investment in R&D is to invest in things that have future promise but are too Blue-Sky for the market to support yet. For every success, DARPA has a dozen projects that never go anywhere. That's just how that game is played.

People should expect cutting edge like this to fail often. That's the whole point. If companies like this were sure bets, they wouldn't need government investment.

<comment><USER5> There's a big difference between funding research, particularly defense- related research, and playing VC, guaranteeing hundreds of millions in loans to build factories. I don't think individual DARPA grants approach that size within an order of magnitude.

What exactly was "blue sky" about Solyndra or A123? Why trust politicians rather than the market to figure out how we'll generate and store energy in the future?

<comment><USER4> Individual DARPA grants are indeed much smaller ($10m is a good sized contract), but it's also free money. Guaranteeing a $100m loan is a much lesser commitment, on average.

As for the market--the market is good at figuring out how to extract maximum efficiency from existing profitable technologies. It naturally under-invests in forward-looking R&D. I'm pretty sure there was a paragraph about this in my Econ 101 textbook in college, in the context of Singapore's massive public investment in R&D and associated massive GDP growth.

<comment><USER6> I would argue (as I do in a separate comment) that A123 seems to fall more in the first category of increasing efficiency in existing profitable technologies (autos and batteries) than in the second category of (pure) R&D. It wasn't a research project. It was a company seeking to introduce a some new applied technology into an existing market (autos.)

</comment></comment></comment></comment><comment><USER7> Not cited in any of the news articles I've read about the bankruptcy is the very nasty patent fight involving A123, Hydro Quebec, and the University of Texas. Some of it is described in this book excerpt:

[http://gizmodo.com/5805875/the-knock+down-drag+out-fight- ove...](http://gizmodo.com/5805875/the-knock+down-drag+out-fight-over-the- next-generation-of-batteries)

You can imagine the distraction and uncertainty that this brought about early in the company's history. The parties finally settled, but not until 2011.

</comment><comment><USER8> I find this sad. Hobbyists loved A123 battery quality.

</comment><comment><USER3> This story/headline at the WSJ seems to have been posted before, but with now updated content. Its fairly even keeled, focusing on the cost/phsyics issues. Here is a relevant summary:

 _At $10,000 a car, the costs of a 100-mile range battery are still prohibitive for a mass-market car, even if gasoline's superiority in range and refueling aren't taken into account. This is one reason why General Motors Co . is rolling out a Cadillac version of its Chevy Volt plug-in hybrid, following Tesla Motors founder Elon Musk's strategy of compensating for the high cost of lithium-ion batteries by marketing his electric car as an alternative to a Porsche. If you want more than 1% of the market to be electric cars, you start by selling to the 1%._</comment>


Ask HN: Review my startup, Devver.net: Accelerated Ruby testing - <AUTHOR>

http://devver.net
Sorry that the service isn't actually available to play around with yet (it's in private beta). If you sign up for our beta list, we'll work to get you an invite as soon as we can.
That aside, what do you think of the idea and site? What isn't clear? What questions do we need to answer?
Thanks in advance for your help! Ben <comment><USER2> Looks very useful.

How about some real world stats, showing that a particular app on a local machine takes X secs to run tests, while with devver it now only takes X

I've just started a new project and am really digging into test for the first time. Tests do seem overly slow, but I'm never sure if its something I'm doing wrong or what. Devver might not help me though as I'm on a horrendously slow connection.

<comment><AUTHOR> Thanks for the feedback! We've been meaning to add some real-world comparisons, but haven't gotten to it yet. Good to know that they would be valuable.

</comment></comment><comment><USER3> I'm a Ruby developer and guessing Devver is for large codebase only, for small code tests are running pretty fast on local machine.

A good point would be on the first screen to specify what kind of tests you are supporting: unit tests, rspec, features etc.

<comment><AUTHOR> You're right - we're currently focused on large code bases with tests that take a few minutes or more. If your tests run in a second, there isn't much we can do for you.

Good idea about specifying RSpec, etc on the front page.

Thanks for the feedback!

</comment></comment><comment><USER4> Maybe it's just me, but "4 times faster" sounds better than "in 25% of the time".

<comment><USER5> That's actually what I came to post too because "Get your Ruby test results in 25% of the time" actually has an alternative, much more negative parsing. Hint: what happens the other 75% of the time?

<comment><AUTHOR> That's a good point. We've been thinking about how to express the speedup more clearly. This is super helpful.

</comment></comment></comment><comment><AUTHOR> Clickable link: <http://devver.net>

</comment><comment><USER6> Hey, Ben -

I'm no developer (actually an interactive copywriter), but I know enough about Ruby to hold a decent conversation.

I agree with timmah - you adequately convey _what_ Devver does, but you're not really giving enough of a value proposition. It just needs a little more "sizzle" to show them why they really NEED to use Devver.

I'm sure some more coder-types will chime in here, but overall, I think it describes the service very well. Good luck!

Kipp

<comment><AUTHOR> Awesome feedback. We'll work on adding more info to really make the value proposition clear.

</comment></comment><comment><USER7> You may want to consider supporting .gems files for specifying additional gem dependencies since that's what Heroku uses. Their customers would potentially be interested in your product also and I couldn't imagine they'd want to maintain two dependencies files.

Is there a way to specify how the tests are split across test machines or the order in which tests are run?

<comment><AUTHOR> There is not currently a way to specify the way tests are split across machines or the order. We're working on a solution but it hasn't been a problem yet for our current users.

Or we might just spin it as a feature - we find order dependencies in your tests!

</comment></comment><comment><USER8> I'm not a Ruby developer so I can't say how well it speaks to that market... but in terms of communicating the idea quickly/clearly and seeming credible - it scores very well. The design is good, not exceptional or super Web styling.

</comment><comment><USER9> You should really try to buy devver.com (godaddy parked site), it will give you more credibility...

<comment><USER10> We have but trust me the price they are asking is unreasonable.

</comment></comment><comment><USER11> Aren't people concerned about sending their code off to your servers? I know that would be a huge issue with many companies.

You're basically competing with LSF, which is well-supported but quite expensive. Maybe you should consider broadening to more languages?

<comment><AUTHOR> You're right, it is a concern for many companies. However, as services like GitHub, EngineYard, and Heroku show, many companies are willing to send their code to 3rd party services if the value proposition is compelling and the security is good.

In the future, we're certainly going to work to support more languages, but we felt it was important to focus on a single language early on.</comment></comment>


Free Website Builder and POS System for Marijuana Retailers Wanna #GetHybrix? - <AUTHOR> http://GetHybrix.com/network

<comment><AUTHOR> We're looking for some Alpha testers to try the system. Visit the site or tweet us @GetHybrix to get started.</comment>


Show HN: My first iOS app. Analytics for Sendy - <AUTHOR> http://sendyapp.co?src=hn <comment><USER2> Very cool! How does it work? Did you develop it yourself?</comment>


On Becoming a Unix Wizard - <AUTHOR> http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/Becoming%20A%20UNIX%20Wizard.html

<comment><USER2> Pleased to see mention of <http://basepath.com/aup/> Most Unix advice prefers to mention Stevens' works (<http://en.wikipedia.org/wiki/W._Richard_Stevens>) but I'm rather partial to Rochkind. (as well, not instead)</comment>


In just a few short weeks we have cast aside freedoms it took centuries to win - <AUTHOR> https://standpointmag.co.uk/issues/may-june-2020/so-happy-to-be-serfs/ <comment><USER2> "I have been trying to point out that quite prominent figures in science and medicine do not agree with the policy of several major governments—that stifling personal liberty and crashing their economies will protect us from the Covid-19 virus. And almost nobody has seriously disagreed with me."

Ok, who are these people? And if their point of view is so strong why aren't they front-page news?

One of the cornerstones of freedom is that individual freedom stops once it impedes on someone else's. We live in a shared society that has limits on everyone's freedom and keeps us from doing anything we want. We have the responsibility for not doing things that will hurt others. In a pandemic, it just so happens that what we do impacts other members of society.

It's true, freedom is important but freedom comes with responsibilities to others too.

And yes, the freedoms are still there, we just have to understand that freedom does not mean doing anything we want all the time.

<comment><USER3> I herald from Italy, basically Ground Zero of the Western impact with the COVID-19 pandemic, so maybe my view is somewhat biased (though I saw it from afar, as I am currently in nearby Malta).

I honestly think it's way too early to fret about lost freedom. There are very valid reasons why certain behaviours must at the present time be enforced or curtailed.

The loss of freedom will only become visible if, once the emergency subsides, the prior ways are prevented from being reinstated. Certainly, some concern is... _understandable_ , at this moment in time, but it's far from a done deal.

I think the right way of framing it is in terms of what (for example) the British endured during World War II: blackouts meant you were not allowed to illuminate anything outdoors during night-time, so as to avoid giving bombers any aid to navigation, and rationing meant that simply having money to spend didn't necessarily suffice to buy what you wanted — both notions that would make latter-day people bristle. And yet that phase came and went, because it was mandated by circumstances, and ultimately the governments of the day had no nefarious reason to deprive their citizens (subjects, actually, in the cause of Britain, but I digress) from the freedoms that they had enjoyed previously once the reason for suspending those freedoms had passed. Not to mention freedom of the press...

So, yes, I can see why people are worked-up about this. But I think the "jury is still out"on these issues. After all, we're in a totally extraordinary circumstance.

</comment></comment><comment><AUTHOR> Key quote:

The freedom to leave your house when you wish to and go where you will is not a civil liberty or a political liberty. It is part of being a free man or woman. Those who do not have it, who fear being scolded like a child, fined and disgraced for being out on the street without government approval, are like serfs tied to the land they work.

<comment><USER3> It's a key quote, but it's not necessarily true, to be perfectly honest. There's a lot of bluster, false equivalences, and hyperbole going around at the moment, and this seems to be a prime example of that.

From where does the analogy flow? We've always had behaviours that are forbidden and places that we cannot trespass upon. This could equally be seen as a (hitherto unprecedented, in recent times) extension thereof. I'm not saying it _necessarily_ is, mind you, just offering it as an equally plausible alternative to show how truly arbitrary the statement is.

As for the notion of a "free man", it seems to be a platonic idealisation on par with that of the spherical cow in a vacuum: a convenient theoretical construct suitable for facile speculation, but not one that encompasses the full gamut of the real world's complexities. There's many things "free men" are not free from and have never been free from even in jurisdictions that nominally subscribe to the notion (in the US, for example: taxes, the draft when it's used, _& cetera_) and these emergency measures are simply a draft of that.

The last one is particularly telling: during WWII the American public were told they were fighting for freedom, and were drafted in droves into the ranks of the military — an act that (obviously) was not voluntary. And yet freedom as a platonic ideal endured.</comment></comment>


Behind the Obvious: years of reading in nudges sent each week via email - <AUTHOR> https://behindtheobvious.substack.com/subscribe#about <comment><AUTHOR> HN, I've been reading for eight years, ~40 books a year. For four of those eight years, I've been collecting ideas and learnings on .md files in a private BitBucket repository.

Every book I read had a folder containing two files: [0] Ideas [1] Learnings.

In `ideas` I wrote the core fundamental ideas upon which the book is structured. Ideas included either author's ideas and others' ideas that he or she might have referenced (directly or indirectly) in the book.

In `learnings` I collected my own learnings.

Ideas are descriptions. Learnings are prescriptions.

I decided to progressively go over the repository, unfold most of the books in it and make it accessible to the public.

While going through this process will help me re-discovering those ideas through a pair of new lens, I thought that others might genuinely enjoy those learnings.

I've framed this project into a bi-weekly newsletter called: Behind The Obvious [0] (about page [1])

[0] [https://behindtheobvious.substack.com/welcome](https://behindtheobvious.substack.com/welcome)

[1][https://behindtheobvious.substack.com/subscribe#about](https://behindtheobvious.substack.com/subscribe#about)</comment>


How to conduct interviews with candidates you already know will be rejected? - <AUTHOR> https://workplace.stackexchange.com/questions/145541/as-an-interviewer-how-to-conduct-interviews-with-candidates-you-already-know-wi <comment><AUTHOR> One aspect that stuck out to me: OP states that he/she is more or less coerced by HR to conduct such interviews. Great example of the lunatics taking over the asylum, in my opinion.</comment>


Game programming patterns - <AUTHOR> http://gameprogrammingpatterns.com/

<comment><USER2> This site is explicitly incomplete. Barely begun, in fact. However, the 'object pool' section has been filled out and has some nice diagrams and explanations.

All in all, I would much rather have seen this link in 4-6 months instead of right now. I'll try to remember to resubmit it around that time.

<comment><USER3> On that note, it'd be nice to have an RSS feed or e-mail notification for when he gets it done.

<comment><USER4> So you want him to implement the Observer pattern?

</comment></comment></comment><comment><USER5> It does look incomplete, but I would like to see a decent resource on game programming for the non-game developer. I consider myself a fairly competent developer but I'm pretty clueless when it comes to AI programming and game development.

<comment><USER6> This is probably not going to be an introduction to game programming, I thinks it's more targeted at those who have already started.

But I think there are other resources for people like you. There are questions about it on stackoverflow, for example [http://stackoverflow.com/questions/174830/learning-game- prog...](http://stackoverflow.com/questions/174830/learning-game-programming)

</comment></comment><comment><USER7> Singelton can't be counted as design patter since dependency injection paradigm been adapted by Java community.</comment>


Mutable Value Chains - c-rack https://joearms.github.io/2015/06/19/Mutable-Value_Chains.html <comment><AUTHOR> It sounds smart. Just swap out the sha1 for public-key signatures and rename the "value chain" to "block chain" and Bob's your uncle.

No but seriously: "SHA which I have chosen in this article has 160 bits, so after more than 2^160 entries have been put into the DHT collisions will occur"

Collisions are largely related to the content that you are hashing. If you are hashing sequential 160 bit chunks of data then Joe's math is theoretically correct. If you are hashing DVD ISO images then you can use math to predict why you should never use sha1.

If you needed to cram it into 160 bits for some hardware reason then you could implement some form of write failure recovery to redistribute writes over them remaining available key space but this would get slower and slower the less and less space you have unless you implement some kind of free space map.

<comment><USER2> So it's just about the address space? SHA 512 would be fine / sufficiently unlikely to collide in real life?

</comment></comment><comment><USER3> > I've been wondering how to do this for years, and suddenly it occurred to me > how to do this. One way that doesn't work is to view the sequence of values > as some kind of linked list, where each value has an invisible write-once- > only pointer to the next value. The write-once-pointer gets updated when the > value is updated, unfortunately this is difficult to implement and there are > problems with consistency.

Why?

> The solution is blindingly simple (once you see it) - we represent the > sequence as a set Key-Value pairs where the Keys are taken from an iterated > sequence of SHA1 checksums. The first key is a random number, thereafter > Key[i] = sha(Key[i-1]).

Why not simply use Key[0] = 0, and Key[i] = Key[i-1]+1, or, in other words Key[i] = i?

<comment><USER4> Because, as I read the article, each key[i=0] represents a single value chain and you're going to have many chains in the store, presumably being written by multiple processes. So if you were inserting based on some global incrementing counter, you couldn't be sure that key[n+1] belonged to the same chain as key[n]. Using iterated SHA1 gives reasonable assurance that key[i+1] will be unique while at the same time making it a function of key[i] so that it can easily be found given that initial key.

<comment><USER3> Then how about using a double key (i,j) where j is the global chain number?

</comment></comment></comment><comment><USER5> >If the sequence of X's is huge then multiple workers can be started tell them to start computing values at different points in the value chain.

How? All the keys need to be calculated sequentially which, depending on the application, can take a significant amount of time. Worse this time grows linearly with the number of cores, so massively parallel calculations with several hundreds, thousands, of cores will become increasingly inefficient.

</comment><comment><USER6> So Datomic over KV storage or DHT? Could be useful, in case of a very efficient implementation.

</comment><comment><USER7> Part CRDT, part blockchain.</comment>


Ask HN: Socioeconomic implications of automation? - <AUTHOR>

For my senior thesis, I'm doing a project on the implications of pervasive automation of almost all production.  My current thinking on the matter is that we're going to see a continuation of rising unemployment in the US and a further divide between a very small number of rich (that own/invent the automated means of production) and the masses of poor unemployed.  It's already happening today (Redbox/Netflix?  Amazon?  Kiva?).  My guess is that we'll see upwards of 30-40% unemployment in the US in the next 30 years.  This clearly isn't a sustainable or desirable (for most) outcome and it seems as though we need a fundamental socioeconomic restructuring in order to avoid total collapse.  Martin Ford's "Lights in the Tunnel" addresses this issue, but there seems to be hardly any other discussion of this topic.  Is the technology just a long way off?  Do most economists just think that the economy will always have a use for all human labor?  What do you guys think? <comment><USER2> I read once that France has way too many highly educated people. The result is that a person can have a Master's degree and be waiting tables. People need to work, regardless of what the larger context is with regards to such things. Yes, context can and does change individual opportunities but people still make choices. Increased automation doesn't necessarily lead to a specific outcome. That is one possibility. Another is that we adapt as a culture and come up with a means to use the freed-up labor of actual thinking human beings for more complex labor, thus allowing society to create something of value which could not exist without freeing up so many people from drudgery.

It's been said that the Chinese word for "crisis" is written with a combination of symbols meaning "danger" and "opportunity". Great change always involves danger. But that doesn't mean that stasis is superior.

<http://en.wikipedia.org/wiki/Chinese_word_for_%22crisis%22></comment>


Dynamic Threshold Selection for Image Segmentation (Fuzzy Logic) - <AUTHOR> https://www.researchgate.net/publication/250170106_DYNAMIC_THRESHOLD_SELECTION_FOR_IMAGE_SEGMENTATION_OF_NATURAL_STRUCTURES_BASED_UPON_A_PERFORMANCE_CRITERION <comment><AUTHOR> The interesting thing about this paper is that the "intelligent" component does not select the binarization threshold directly, but is contained within a loop (see figure 1) which iteratively adjusts the threshold.</comment>


Educated parents have educated kids. Genes aren't the reason - <AUTHOR> https://www.bostonglobe.com/business/2018/09/10/educated-parents-have-educated-kids-genes-aren-reason/3LRRnotV5RPxmwEJ4ssf6M/story.html <comment><USER2> The amount of time one spends in an academic institution is a poor indicator of genetic influence.

May as well searched genetic markers for time spent at the gym, rather than athletic performance.</comment>


Debunking the Cul-de-Sac - <AUTHOR> http://www.citylab.com/design/2011/09/street-grids/124/ <comment><USER2> This article seems to totally gloss over the advantages of cul-de-sac and suburban living. Having just moved from the a more dense area of the city (after 10+ years) to a much more suburban area, I am keenly aware of the new perks I now have.

The first one is obviously space. Suburbs can have bigger houses and bigger yards. That is a very nice perk. I am not saying that bigger is always better, but you can't just dismiss this as not being important at all. Having a backyard where I can BBQ and a garage I can park in are pretty nice.

Second, the article talks about the increased overall danger from traffic accidents in the city, but they don't talk about actual accidents in the cul- de-sac itself. If you live in a cul-de-sac, your kids can play in the street much more safely than if you are in a city grid. Being able to play in the street is a nice thing.

Again, I don't think that there isn't a cost to suburban cul-de-sac living, I just feel this article completely ignores the actual benefits, instead focusing on a few parts that I don't think people are actually claiming about the suburbs.

<comment><USER3> This has been a really common theme of city planning discussions on HN. A lot of urban dwellers don't understand the appeal of suburban living, and would rather brand it as "wrong" than accept that not every living situation is there for their preferences.

<comment><USER4> A lot of us grew up in a suburban setting, and did not like it. We moved to an urban setting for a reason.

<comment><USER5> I grew up in a small town and thought life there was pretty good until I moved to a city for university. Once I got a taste of living in a city, I didn't think I would ever return and couldn't understand why so many people live out there.

Then I had kids and we moved to the suburbs and I like living here better than any place I've lived before. Once self-driving cars are a thing, I'm buying one and moving even further out of the city.

Interestingly, there's been a lot of office space being built around me. I think companies that have a lot of suburban employees are moving to the suburbs (including my employer).

<comment><USER6> > _I think companies that have a lot of suburban employees are moving to the > suburbs (including my employer)._

Probably so. It's cheaper than urban office space, and they probably figure everyone's driving anyway (which is pretty much guaranteed true after they move to the suburbs).

</comment></comment></comment></comment></comment><comment><USER7> Did I miss something? I don't see anywhere where it "debunks" anything.

It has some talk about traffic accidents when you travel outside of a cul-de- sac, but doesn't talk about the increased safety inside (especially for say children who play in the area), doesn't talk about crime rates, or any of the reasons people move into suburban areas. It throws in some off the cuff comment about being more connected, but doesn't say why that would be true in a more densely populated grid layout (as opposed to knowing your neighbor more in the the suburbs).

The article seems really poor actually, rushed to meet a deadline.

<comment><USER8> Suburbs full of cul-de-sacs are terrible places to grow up for children after the age of about 6. They're invariably designed to be incredibly pedestrian- hostile, and usually also bicycle-hostile, so if you don't drive a car, you either need to have your parents drive you everywhere, or you need to have every possible destination within a couple blocks.

Such an environment is stifling of children's independence and community interaction.

<comment><USER9> When I was a kid I rode a bicycle.

<comment><USER10> I think the difference is, in a suburb a kid can safely ride a bicycle. That's great, if your goal is to ride. If your goal is to _go to somewhere specific_ (movie theater? soccer game? swimming pool?), kid probably needs a ride in a car, because those places aren't within biking distance for a kid.

</comment></comment></comment></comment><comment><USER11> I live in Davis CA (briefly) mentioned in the article and grew up in Pittsburgh PA. Pittsburgh PA placed in the top 10 worst cities to bike in, several times. The main problem is that the neighborhood streets don't go anywhere, they just feed you onto busy streets with speed limits of 35 mph and up, with minimal shoulders.

So even for a 7.5 mile commute you end on up fairly dangerous roads for bikes. On the bridges you have to choose between really dangerous and legal (no shoulder at all, with a big railing between you and sidewalk), and illegally using the sidewalk.

Things like a local school, grocery store, drug store, and even a pizza joint are often pretty far away. You have to skip several useless neighborhoods on a major thoroughfare to be able to shop.

In davis there's a large downtown section that's largely a grid, low speed limits, bike lanes, and reasonable shoulders. The surrounding neighborhoods often have a green belt, and when they don't there's pretty much always a reasonable parallel road to any major through fair. There's much more retail space mixed into the neighborhoods. There are schools, parks, drug stores, and restaurants spread around the city, not just downtown.

Pittsburgh does have a grid like downtown, but it's pretty much exclusively a business district, very few people actually live there. It seems fairly post apocalyptic after hours with no cars and no foot traffic, just the rats scurrying around.

Seems like all the best cities have mixed use zoning, large grids, and highly connected streets. This allows for biking, walking, and of course better public transportation while minimizing high speed vehicles mixing it up with bikes and pedestrians.

<comment><USER12> Pittsburgh's neighborhoods are also heavily segregated by geography. You really can't go more than maybe a mile being generous, ½mi more likely, without hitting a major elevation change. Additionally, we're starting to add better support for bikes; it's not super great, but it's getting a lot better than even 5 years ago.

</comment></comment><comment><USER13> Having lived in all different types of road patterns, the number once thing that increases safety is population density.

The lower the density, the safer, and the better for children. Everything is more pleasant, less noise, less wasted time, room for kids to play, less conflict with neighbors.

There's more driving, but I don't care, everything else is so much better it's worth it. And don't forget that even with the driving, everything takes less time.

So do it - design "for cars" if you want to call it that - you are really designing for the people _inside_ the cars, and they will be much happier.

If that means a cul-de-sac ("dead end" as I've always called it) do it.

<comment><USER14> We've seen experiments globally where highly planned developments, and even 'projects' fail.

However I am unaware of any experiments, natural or otherwise, with systemic encouragement of desired development goals.

I see no environment in cities, suburbs, or rural areas where there is a strong vision and drive towards building community.

<comment><USER15> Seems like what you're describing is a planned community or also intentional community. The latter being more of focused on the community part and the former on the planning part. Washington DC is a planned community.

[https://en.wikipedia.org/wiki/Planned_community](https://en.wikipedia.org/wiki/Planned_community) [https://en.wikipedia.org/wiki/List_of_purpose- built_national...](https://en.wikipedia.org/wiki/List_of_purpose- built_national_capitals)

[https://en.wikipedia.org/wiki/Intentional_community](https://en.wikipedia.org/wiki/Intentional_community) [https://en.wikipedia.org/wiki/List_of_intentional_communitie...](https://en.wikipedia.org/wiki/List_of_intentional_communities)

</comment></comment></comment><comment><USER16> The article somehow seems to conflate road layout with population density, peppered with some vague arguments in favour of high density building.

I agree that a lot of America's traffic problems are related to their low- density suburbs, and there are many arguments why these suburbs are not all that great. But that is completely seperate from road layouts: you can build a cul-de-sac with high-density buildings, add a few footpaths and get basically all the advantages listed.

<comment><USER17> I got exactly the same impression. The cul-de-sac _per se_ isn't even addressed. Taking it as symbolic, the article's main argument for grid layouts seems to be little more than "everyone was doing it 100 years ago, and we found a handful of favorable correlations, so they must have been on to something".

</comment></comment><comment><USER18> I'm going to repost a comment from citylab page:

This piece is lying or deceptive, depending on your perspective. The Roman Empire may have built cities on grids, but most major European cities are generally not on grids, at least not in the sense of American cities. Just have a look at London, Berlin, Paris, Amsterdam, Copenhagen, Rome and many more. They are full little side streets that head off in unpredictable directions. They're not full of Cul-de-sacs, though, as most streets are not dead ends. But, don't pretend that the main alternative to cul-de-sacs is the American grid. Both are awful, compared to Paris! Without being an expert, I would guess that what makes European cities more enjoyable that American ones (they usually are!), is that they have many streets that are for pedestrians only - this makes for a much more enjoyable experience walking the city, and creates lots of wonderful spaces for restaurants and other venues to have outdoor seating.

\- by wowsuchgoodpoint

<comment><USER19> The point isn't that streets are for pedestrians - the point is that the streets are not single-purpose.

The street I lived on in Stockholm had a life cycle like:

\- 6am - early people head to work

\- 8am - kids head to school

\- 10am - parents with baby strollers pass by on their way to cafes

\- 11am - first people show up for lunch at the square

\- 12pm-2pm - bulk lunch traffic

\- 4pm - people start coming back home

\- 5pm - people going shopping down the street

\- 6pm - shops start closing, shop keepers fiddling with their things

\- 7pm - dinner guests start passing by on their way to the restaurants

\- 11pm - last restaurant guests start heading home

Compare that to the cul-de-sac I now live on in the US:

\- 6am - people start leaving, everyone drives

\- 10am - all cars are gone at this point

\- 5pm - people come home, all in cars

The difference here has nothing to do with grid or windy streets, it has to do with mixed use buildings and streets built to be used for multiple purposes.

The effect is quite substantial: In the Stockholm neighborhood, I always felt safe, always had neighbors going places on the street.

In my US neighborhood, the streets are almost always empty. No one has a reason to come here for most of the day. This is why the local PD posts a patrol car at our dead-end cul-de-sac every Saturday night, because otherwise people come out here to smoke pot, since there's never anyone around

</comment></comment><comment><USER20> I live in Edmonton, AB, and it somewhat follows a grid system. Although, a bunch of newer nieghborhoods have not continued to follow it. The roads all have numbers in a predictable pattern. This is very helpful for navigation, as just giving someone an address means they will probably be able to find it without consulting a map. Named streets automatically imply that I cannot find an address at all without a map. You can't even find out which general direction would be correct.

<comment><USER21> Worse yet - go to Calgary where they've named all the roads in a given neighborhood with the same name. E.g.: Eversyde Blvd, Eversyde Cir, Eversyde Manor, Eversyde St. It's insanity.

(Lived in Edmonton, Calgary, and now Lethbridge. Always fun to see another Albertan on here. :P )

<comment><USER22> As a former Calgarian I feel obligated to provide an example of this:

[https://www.google.com/maps/place/Calgary,+AB,+firstname.lastname@example.com...](https://www.google.com/maps/place/Calgary,+AB,+email@example.com,-114.241329,17z/data=!4m5!3m4!1s0x537170039f843fd5:0x266d3bb1b652b63a!8m2!3d51.0486151!4d-114.0708459)

</comment></comment></comment><comment><USER23> In Massachusetts both in suburb and city we have almost complete chaos.

I'm almost sure we do no have the "grid" nor "curvilinear" nor "cul-de-sac" (my house is older than all of those designs by ~130 years). What we have is streets that follow natural features (e.g. the Charles River).

The irony is Massachusetts despite its urban legend of having horrible drivers is one of the safest states to drive in [1] (there are many more references).

[1]: [http://www.autoblog.com/2014/07/23/traffic-accident-death- od...](http://www.autoblog.com/2014/07/23/traffic-accident-death-odds-by- state/)

<comment> xkcd-sucks It seems like many states are known for having the worst drivers, while none are known for having the best

<comment><USER24> The states that have a distinctive "style" of driving, which isn't close to the "average" national style, are known for having bad drivers, by visitors who aren't yet comfortable with the local style.

</comment></comment></comment><comment><USER25> The article claims cities should not be trees, but I don't think grids are better. I'm a big fan of Christopher Alexander's claim that successful cities are actually semilattices:

[http://www.bp.ntu.edu.tw/wp- content/uploads/2011/12/06-Alexa...](http://www.bp.ntu.edu.tw/wp- content/uploads/2011/12/06-Alexander-A-city-is-not-a-tree.pdf)

</comment><comment><USER19> Highly recommend [http://www.strongtowns.org/](http://www.strongtowns.org/) if you are interested in articles like this; still trying to explain to city councils over a hundred years after Ebenezer wrote "To-Morrow" ([https://en.wikipedia.org/wiki/Garden_city_movement](https://en.wikipedia.org/wiki/Garden_city_movement)) why he was horrifically wrong.

If you want to dive deeper into this, Jane Jacobs's "Death and Life of the Great American Cities" is an incredible and very approachable book on urban planning: [https://www.amazon.com/Death-Life-Great-American- Cities/dp/0...](https://www.amazon.com/Death-Life-Great-American- Cities/dp/067974195X)

</comment><comment><USER26> My work life for the past few years has been a constant effort to not work downtown. I don't want to live or work there. It is a miserable concrete hellscape. Dirty, unkempt, infested with beggars and other indigents. The concept of a legitimate grocery store is something that has not existed there for decades. This is all fine if you can survive off of craft beer, gourmet cupcakes, and takeaway for the rest of your life. But the city keeps making sweetheart tax deals for desirable employers. And I keep getting the news "We are moving the office downtown! Isn't that great!"

It's great for somebody, but not the average working stiff.

</comment><comment><USER27> I've noticed over the years that Palo Alto's residential areas started with a grid system but moved towards a cul-de-sac by blocking off roads to cut off parts of the grid. The College Terrace area is particularly notable (likely because of its proximity to employment centers like Page Mill's corporate campuses and Stanford University), and I seem to recall the Old Palo Alto area having some road blocks as well (particularly the area directly south of Palo Alto High School).

It definitely makes the quality of life better for the residents while making commuters "pay more" so to speak. I wonder when these road blocks (which are visually pleasing with trees and pedestrian and cyclist permeable) came to be.

</comment><comment><USER22> When self driving cars take over, Get ready for the revival of suburbia.

Whatever progress migration toward densely populated urban areas has made in recent year (due to traffic and high gas prices) is going to rescind.

<comment><USER5> I think you are right about that. Self-driving cars are going to lower the cost of trips and car ownership and I think that can only lead to more trips being made and cars being owned.

I can't wait to buy one.

<comment><USER28> Why buy one? Just use Uber or similar.

<comment><USER5> Because they are going to be very affordable (eventually) and it's nice to be able to leave stuff in your car. People already spend far more on cars than they need to and that's not likely to change.

<comment><USER29> Why would they possibly be cheaper than current human operated cars?

<comment><USER5> The cars will be mechanically simpler (electric motor connected to wheels without a traditional gearbox), require less maintenance (no oil changes), be cheaper to insure, and inexpensive to operate. The electronics and software will do what they always do - get better and less expensive. Lighter cars that don't crash (often) can be made from different (cheaper) materials than current cars. They will be similar to today's golf carts. I think a basic car will cost less than $10,000.

A lot of the same innovations that go into producing a self-driving car apply to the construction and repair of the car itself. One of the most expensive parts of a new car is paying for wages, benefits, and pensions for the people that made the car. I'm thinking self-driving cars will be built and serviced by other machines. I would bet that before long, you buy a car the same way you buy a cell phone. You subscribe to a plan and upgrade every 2-3 years. Maybe you would subscribe to a shared fleet for $50 / month or maybe you "buy" your own car for $250 / month.

This is all assuming a few years have passed and human driven cars are rare.

<comment><USER29> Car prices historically haven't done that. The typical inflation adjusted price for a car is the same as it was 100 years ago, as automation and technology improve manufacturers add features rather than lowering prices. Current cars are almost entirely built by robots as it is, not much more gains to be had there.

<comment><USER30> "Car prices historically haven't done that. " ... in the United States.

Let's take a cheap car from the 1960s, an Austin Mini Cooper.

A 1960s Mini Cooper was about 500 pounds. That's 10.000 pounds in today's money.

Today you can buy a Dacia Sandero for 6.000 pounds. That's almost half of a Mini Cooper.

[http://www.thisismoney.co.uk/money/cars/article-2232885/Top-...](http://www.thisismoney.co.uk/money/cars/article-2232885/Top-5-cheapest- brand-new-cars-buy-Britain.html)

<comment><USER29> Or you could get a Mini Cooper today for around 16.000 pounds. In the 1960s you could get a Trabant for less than than the Mini too if you're comparing English vs Romanian cars.

<comment><USER30> The point I was trying to make is that "automation and technology" can lower prices.

The current Mini is nothing like the old Mini, it has billions of features more (exactly the point you were making in the original post I replied to).

I can't find any sources, but I strongly suspect that an inflation-adjusted Trabant would be much more expensive than a Dacia Sandero.

Edit: I found some sources which confirm my hunch. A Trabant would be 11.000 pounds today if bought at East Germany prices, and 5.500 pounds if bought at West Germany (subsidized) price. The same source says that the Mini destroyed the Trabant market, they competed at similar price points.

A Maruti 800, which would be a much better comparison to the 60s Mini or Trabant, should probably cost about 4000 pounds in the U.K.

Source for Trabant prices:

[http://heinkelscooter.blogspot.com.uy/2014/01/trabant- east-g...](http://heinkelscooter.blogspot.com.uy/2014/01/trabant-east-german- peoples-car.html)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Cul-de-Sac hase one enormous advantage - Google and Waze will not be able to send tons of traffic through your little street.

</comment><comment><USER32> Simple, if you put in a huge section of housing without services in walking or good mass transit distance, people will be forced to drive there. Thus negating advantages of the cul de sac while making the congestion much worse.

Fixing means a return to mixed developments, but you can still keep the cul de sac structure.

Another broken thing recently appearing is gated "communities" adding impassable terrain to the landscape.

</comment><comment><USER33> These things always devolve into a shouting match between the planners and people who value solitude or a big yard. I agree with the anti-density folks on one thing: big yards are awesome, larger houses are very useful, and I want my kids to feel safe on my street, and I find it hilarious that planners have so little humility--they curse the foolishness of the previous generation of planners, who overlooked some very important details, and then proceed to lay out _their_ broad-brushed scheme for utopia. What could possibly go wrong?

But I'm convinced of the following: driving has huge costs that are not internalized as part of the decision-making process about whether to drive somewhere or not. E.g.:

\- driving presents a large risk to pedestrians or bicyclists nearby

\- driving requires a large amount of incredibly expensive infrastructure to be custom-built to support it

\- driving down a street makes that street a less pleasant place to be, in general, due to noise, perceived risk, etc.

\- driving causes congestion, which delays other drivers

\- pollution and environmental costs

So if people actually paid the full cost of their trips, they'd probably drive less, and would be much less likely to plan their lives in ways that require large amounts of driving. For some people, the benefits would be worth the costs, and more power to them--but I shouldn't have to subsidize that choice.

I wish the debate could be less about what type of lifestyle we prefer, and more about how to fairly distribute the costs of our choices.

<comment><USER34> No one pays the full cost of their trips. Transit users are subsidized. Pedestrians and cyclists are subsidized as they pay nothing at all for their infrastructure. Plus, every "drivers are subsidized" argument ignores the fact that drivers shoulder the entire capital and operating expense of their vehicles--a cost borne entirely by governments for transit. Even transit systems with high fare box recovery rates do not come close to paying even one penny of _any_ of their capital expense, whether for guideways or for vehicles.

<comment><USER24> _Pedestrians and cyclists are subsidized as they pay nothing at all for their infrastructure._

Comparisons across many orders of magnitude are not insightful. Pedestrians and cyclists can travel over unimproved ground, or gravel if they're being picky. Any road that currently serves automobiles could serve the same number of drivers as pedestrians and cyclists for centuries with no maintenance.

</comment></comment></comment><comment><USER35> The article did not discuss the advantages that my cat(s) obtain from not being crushed beneath the wheels of passing traffic on a more regular basis. [note to purists: "our cats" are kept strictly inside, but there are stray cats that we feed, and have survived for many years without auto crushing on a cul-de-sac].</comment>


Machine Learning on Encrypted Data Without Decrypting It - <AUTHOR> https://juliacomputing.com/blog/2019/11/22/encrypted-machine-learning.html <comment><USER2> Since there seems to be a lot of confusion throughout this thread, perhaps I can attempt to clarify what's going on at a very high level. The setting is that the user sends their data to a service and wants the service to do useful work on their data without knowing what their data is. In this case, the work that the service does is apply a pre-trained, non-secret ML vision model to the secret, encrypted data. The result is an encrypted answer that is sent back to the user, who can decrypt it and get a useful result. The service is none the wiser about what the user's data was, nor what the answer was.

Does this seem like impossible magic? Yes. Everyone was pretty surprised when the first theoretical fully homomorphic encryption schemes were found. For a while people believed that it might never be efficient enough to be practical. But now it's actually feasible to do limited but real useful computations on behalf of a user without the service learning anything about what it is computing for the user. There is ongoing work to expand what kinds of computations can be done efficiently.

<comment><USER3> Sounds strange. Does this mean that the model has to be trained on encrypted data?

<comment><USER2> Yes, it's rather surprising that it can be done at all. And no, you train the model normally and then express the application of the model in terms of the set of primitive operations that the encryption scheme supports. Broadening the set of operations supported by the encryption scheme is an active area of research since having a better "instruction set" allows more computations to be done efficiently.

It is also possible for the model to be provided by the user and encrypted along with the data rather than being fixed and public. That way the service can apply a model that it doesn't know to data that it also doesn't know. This allows a fairly general service in theory, but it remains a challenge to express more than fairly simple models in a way that can be computed efficiently.

<comment><USER4> I don't understand why it has to be trained on encrypted data. Isn't it faster to train on the cleartext data (and of course use the same instruction set, the unencrypted counterpart of it)?

<comment><USER5> I think he is saying that you do the training on cleartext data.

<comment><USER4> Ah ok, his first "yes" confused me so much that I saw no value to read further.

</comment></comment></comment></comment></comment></comment><comment><USER6> Before reading: "I bet they're using homomorphic encryption to expose patterns in the encrypted data"

After reading: Yup. It makes sense, so long as your resulting model is run against similarly encrypted data, the same patterns will be there for the ML to identify.

Which is, of course, one of the issues with homomorphic encryption.

<comment><AUTHOR> Just to clarify, homomorphic encryption does not expose patterns. At every point in the computation the ciphertexts are computationally indistinguishable from random. The result of evaluating the ML model will be an encrypted prediction that you then need to send back to whoever encrypted the data (or more precisely whoever has the key - doesn't need to be the same person) so they can decrypt and use the prediction.

<comment><USER7> Do you have a reference somewhere that backs up your assertions, where I can read more on this topic? I'm super curious about it.

<comment><AUTHOR> The CKKS paper that describes the crypto scheme I'm using is described here: [1]. The paper is decently readable, but frankly I feel that it doesn't really convey much intuition and it's a bit hard to follow if you don't have an algebraic number theory background. Probably the correct thing to do is to read the original BGV paper [2], which is still quite technical of course, but at least doesn't implicitly assume all the development that has happened since then. Once you've gotten the basics, I have an overview that focuses more on the practical aspects of how it works in the documentation [3]. I've also written an overview of how CKKS works, in which I've tried to highlight what the two main ideas of CKKS are compared to earlier schemes [4]. Let me know if you were looking for something else.

[1] [https://eprint.iacr.org/2016/421.pdf](https://eprint.iacr.org/2016/421.pdf)

[2] [https://eprint.iacr.org/2011/277.pdf](https://eprint.iacr.org/2011/277.pdf)

[3] [https://juliacomputing.github.io/ToyFHE.jl/dev/man/backgroun...](https://juliacomputing.github.io/ToyFHE.jl/dev/man/background/rlwe/)

[4] [https://juliacomputing.github.io/ToyFHE.jl/dev/man/ckks/](https://juliacomputing.github.io/ToyFHE.jl/dev/man/ckks/)

<comment><USER7> this is great, thank you.

</comment></comment></comment></comment></comment><comment><USER8> This blog post reminds me of the "Machine Learning Systems are Stuck in a Rut" paper [1], where they mentioned:

> It is hard to experiment with front end features like named dimensions, > because it is painful to match them to back ends that expect calls to > monolithic kernels with fixed layout. On the other hand, there is little > incentive to build high quality back ends that support other features, > because all the front ends currently work in terms of monolithic operators. > An end-to-end tool chain for machine learning requires solutions from many > specialist disciplines.

This is a fantastic example of getting around this problem using Flux.jl's interaction with the full Julia language. Here the author does some exceedingly cool stuff (doing machine learning on encrypted data!), and in order to get there he needed to write what many would think of as lower-level kernels that should be "provided by the library" (encrypted matrix multiplication, encrypted convolutions). To make the interface useful, he needed to use a mature interface that people are already using and make it something that can automatically switch over to encrypted implementations. And, because of the nature of fully homeomorphic encryption, the implementation has to be fast, otherwise it's dead in the water since FHE is expensive!

To me, this example showcases one way how Flux.jl's is helping machine learning get out of that "rut". The author adds dispatches to standard kernels which allow for his encrypted data types, which then allows standard Julia Flux.jl machine learning models to act on encrpyted data, and it uses type- inference + JIT compilation to make it fast enough to work. Not only that, but it's also not tied to some "sub-language" defined by a machine learning framework. That means the FHE framework not only works nicely with machine learning, it can be used by any other package in the Julia language (differential equation solvers, nonlinear optimization, macroeconomics models?). This allows composibility of tools and community: all tools from all fields can now use this same FHE implementation, so authors collaborate and mature this to a very good one. These knock-on effects give people doing research in Julia a lot of competitive advantages over other researchers, and it will be interesting to see how this effects not just the ML research community, but also everyone else!

[https://dl.acm.org/citation.cfm?id=3321441](https://dl.acm.org/citation.cfm?id=3321441)

(Repost from the previous thread on this!)

<comment><USER9> Julia always seemed great on paper and definitely is a strong candidate for replacing Matlab. But whenever I tried using it, the user experience seemed much more broken than python or c++. It just seems way easier to structure and work on a python + c++ project than it is to structure and work on a Julia project. A moderately sized sane c++ code base compiles and runs faster than whatever gymnastics Julia performs to create a single 2d plot (literally freezes my laptop for seconds). It also installs gigabytes worth of libraries into global directories by default. The compiler itself is also of questionable quality compared to clang, Swift or Ocaml.

<comment><USER10> > literally freezes my laptop for seconds

Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem:

[https://github.com/JuliaLang/julia/issues/28092](https://github.com/JuliaLang/julia/issues/28092)

[https://github.com/JuliaLang/julia/issues/17285](https://github.com/JuliaLang/julia/issues/17285)

[https://github.com/JuliaLang/julia/issues/4452](https://github.com/JuliaLang/julia/issues/4452)

[https://github.com/JuliaLang/julia/issues/1064](https://github.com/JuliaLang/julia/issues/1064)

[https://github.com/JuliaLang/julia/issues/260](https://github.com/JuliaLang/julia/issues/260)

<comment><USER11> What do you mean by "refuse to show willingness to fix or even acknowledge the problem"? Do you realize that two of those issues were started by core contributors?

</comment></comment></comment></comment><comment><USER12> As somebody with some ML background but no expertise in crypto, is the following ELI~20 summary correct?

We take an ML model trained on unencrypted data, use a 'homomorphic evaluation' technique (let's just leave that as magic here) to convert the model operation-by-operation to a model that runs on encrypted data, do a little more crypto magic, and we've solved the business problem described at the beginning of the article.

(In particular, if you train a model on encrypted data you get a really bad model, right?)

<comment><AUTHOR> Yep, that's correct. With the minor caveat that we choose an ML model that's "easy" to evaluate using homomorphic encryption.

<comment><USER13> As someone who is not a cryptography expert, is there any hope of using similar logic to train on encrypted data? Naively it seems like you could perform the same operations on the back propagation steps (or any other update algorithm you're using for non NN models) to arrive at the encrypted version of the parameter updates, which you could then decrypt to get the updated model. Am I missing something here?

<comment><AUTHOR> Training is a lot tougher. Just doing one gradient update step isn't all that bad (although you may have to play with the loss function a bit, e.g. logit cross entropy is probably tough to evaluate). However, then you need to go and actually do all the steps and gradient updates, so you probably need some form of bootstrapping to be able to evaluate computations of that depth. Also, the use case is slightly less compelling. For training, you can probably get all the parties who have data to coordinate and evaluate an MPC more cheaply than you could with HE alone. I think it'll require a very compelling use case for somebody to go and think through what the best way to do it is and it'll probably depend on the specifics of the application (who has what data, and what are we willing to leak as we go along - e.g. it's a lot easier if you don't care about keeping the weights secret).

<comment><USER13> There are definitely compelling use-cases and there are people working on it (though not me). Developing tools/systems to handle sensitive data in a secure way is extremely expensive and time consuming. If you can create data collection and model training pipelines that can operate effectively with just encrypted data then you greatly reduce the number of vulnerabilities (e.g. fewer employees need to actually see the sensitive data and fewer points of attack on the system itself).

There are certainly a number of factors to consider besides data security when evaluating the practicality of such an approach but I just wanted to confirm that it was technically possible before getting in to any of that. Thanks for your response and the post, I knew almost nothing about HE before today.

</comment></comment></comment></comment></comment><comment><USER14> With Homomorphic Encryption, the data owner encrypt data _X_ , and give C(X) it to the owner of the function _f_ applies it to _C(X)_ , which gives _f(C(X))_ , which equals to _C(f(X))_ and return it to the data owner, which can decipher it to _f(X)_. The owner of the function know neither the initial data nor the result, and the owner of the data doesn't know _f_.

There is also Functional Encryption, a different technique solving a similar (but different) goal. With F.E., the owner of the data must know the function _f_ , but the party performing the calculation get directly the result _f(X)_.

</comment><comment><USER15> This sounds like what Microsoft research did with SEAL to produce CryptoNets

[https://www.microsoft.com/en- us/research/publication/crypton...](https://www.microsoft.com/en- us/research/publication/cryptonets-applying-neural-networks-to-encrypted-data- with-high-throughput-and-accuracy/)

<comment><AUTHOR> Yep, same research setting, though a different network. I don't at the moment remember all the details of CryptoNets, but IIRC they were doing batch size 8192 evaluations (i.e. just using each slot as an independent value and evaluating the code as if on scalars), which allows you to get away without the fancy ciphertext encoding magic that's described in the blog post (at the cost of high latency of course).

<comment><USER16> You're right, CryptoNets used a data layout optimized for throughput with a batch size 4096. Since then we've done a lot of work on low latency inference with our CHET compiler [1] and my colleagues with LoLa [2]. It all comes down to the data layouts you use.

[1]: [https://www.cs.utexas.edu/~roshan/CHET.pdf](https://www.cs.utexas.edu/~roshan/CHET.pdf) [2]: [https://arxiv.org/pdf/1812.10659.pdf](https://arxiv.org/pdf/1812.10659.pdf)

</comment></comment></comment><comment><USER17> "True homomorphic encryption isn't possible, and my guess is that it will never be feasible for most applications. But limited application tricks like this have been around for decades, and sometimes they're useful" \- Bruce Schneier [https://www.schneier.com/blog/archives/2019/07/google_releas...](https://www.schneier.com/blog/archives/2019/07/google_releases_1.html)

<comment><USER2> I don't understand what Bruce Schneier means by this quote. Several fully homomorphic encryption schemes have been proposed and implemented. "True" doesn't have a technical meaning in this context, so it's unclear what's he means by that phrase. Perhaps that he believes it will never be fast enough for general computations? Or perhaps he's referring to the fact that schemes don't allow conditionals?

</comment></comment><comment><USER18> There's a PyTorch-style library for that: [https://github.com/facebookresearch/CrypTen](https://github.com/facebookresearch/CrypTen)

</comment><comment><USER19> I wonder if you could apply the same homomorphic encryption to ML model training as well, so that you can fully train an algorithm without ever being able to actually "see" the training data.

</comment><comment><USER20> You know what's interesting?

Aren't hashes etc. done by some nonlinear functions?

Doesn't ML kind of try to fit your model using linear functions all the way down? Or not only linear?

Point being — can ML techniques be used to reverse hashes or find collissions? Immovable object vs irresistible force?

Anyone got actual INFO on how this plays out?

<comment><USER21> > Point being — can ML techniques be used to reverse hashes or find > collissions? Immovable object vs irresistible force?

That's actually a good philosophical observation. And there is an answer for that.

If you try to use ML on an encrypted data set then it will blow up and won't converge. The encrypted data contain a lot of randomness while the ML would assume the presence of a not insignificant amount of continuity, linearity and correlation.

Trying to train a network on encrypted data would blow it up as it would not be able to find a convergence point in any observable time. The effort would be equivalent to trying to bruteforce the encryption.

But if you have a few million years, a few PBs of storage and some extravagant network training algorithm based on mutations, who knows.

</comment></comment><comment><USER22> Not sure I totally grok this, but this has been around for a while to use tensorflow on encrypted data [0]

[0] [https://github.com/tf-encrypted/tf-encrypted](https://github.com/tf- encrypted/tf-encrypted)

<comment><USER16> TF Encrypted has focused more on MPC [1]. At least that's what their arXiv paper [2] talks about. It does seem they are also working to integrate Microsoft SEAL for HE.

[1]: [https://en.wikipedia.org/wiki/Secure_multi- party_computation](https://en.wikipedia.org/wiki/Secure_multi- party_computation) [2]: [https://arxiv.org/abs/1810.08130](https://arxiv.org/abs/1810.08130)

</comment></comment><comment><USER23> I'm assuming this uses similar encryption algorithms that you can use to do queries on encrypted data?

<comment><AUTHOR> I'm assuming you're referring to private information retrieval ([https://en.wikipedia.org/wiki/Private_information_retrieval](https://en.wikipedia.org/wiki/Private_information_retrieval)), which is from the same field of research, but may or may not use the same techniques.

<comment><USER23> Never looked into it. Just heard about it recently. Very cool.

</comment></comment></comment><comment><USER24> Wow! Does this mean translating a program from one language to another using ML will be possible?

</comment><comment><USER25> Think about what encryption should do. Think about what Machine Learning should do. The only thing you can do with ML on encrypted data is show where encryption needs to be improved. Or maybe there is a way to create ML models that produces output which only someone with the correct (private) key can understand.

<comment><AUTHOR> > Or maybe there is a way to create ML models that produces output which only > someone with the correct (private) key can understand.

Yes, that's what the blog post describes how to do.

</comment></comment><comment><USER26> very nice machine learning releted post amazing share information thanks by @KenoFischer

</comment><comment><USER27> What are the runtimes?

<comment><AUTHOR> About a minute or so for the batch of 64, but I haven't tuned the implementation yet (I just did enough work to get it down to a comfortable range of experimentation). The paper I linked ([https://eprint.iacr.org/2018/1041.pdf](https://eprint.iacr.org/2018/1041.pdf)) which uses the same model, but with a more optimized implementation cites 26ms amortized per image (in a batch of 64), so I would suspect I can get down to that with a day or two of optimization work if I wanted to (or just plug in their backend - but where's the fun in that).

</comment></comment><comment><USER28> How is this new in 2019, as the article states? Fully homomorphic encryption has been around for at least a decade. There's even a hedge fund (numerai) that crowdsources its quantitative modeling based on an implementation of FHE since 2015.

</comment><comment><USER29> This technique is deeply flawed.

You can't do this effectively without outside knowledge they should not have. They are in fact using outside knowledge, specifically that the encrypted data is in the form of images. Without that knowledge, you wouldn't know which ML techniques to use! Additionally, remember that feature engineering is a big part of what makes ML effective at all, and that certainly cannot be done on encrypted data (the feature engineering you need to do depends on what the data looks like).

<comment><USER30> If I don't even know what data type my input is, what meaningful output can the system give? I wouldn't consider that cheating.

Also, you can do feature engineering on a training set that you collect, as long as that is similar to the distribution of end user inputs. That's a pretty standard ML workflow.

<comment><USER29> The entire point of encrypted data is you don't know what's in there. What they're claiming is they've worked around this problem, but they haven't, because they're subtly incorporating outside information: specifically that they know what the data looks like already. From a true third-party looking at encrypted data, you would have no idea.

What does your statement about feature engineering have to do with encrypted data? Maybe I can clarify with an example: You can't transform a waveform into more usable features with a fourier transform if the waveform is encrypted.

<comment><USER31> You seem to be misunderstanding the value proposition. Suppose that I have some of my personal medical data, and I'd like to use it to try and detect early symptoms of HIV. But because there's a stigma against HIV and I don't trust medical providers to handle my data correctly, I refuse to hand over my data to a third party service unencrypted. Without homomorphic encryption, I'd be out of luck; I couldn't use a third-party service to analyze my data and return a prediction.

With homomorphic encryption: \- I encrypt my data locally \- Send the encrypted bits over to the third-party \- The third-party uses their ML algorithm to compute a prediction \- They send back an encrypted prediction \- I decrypt the prediction locally and get my results.

At no point in this process can anyone, aside from me, see either the input data or the output.

</comment></comment></comment></comment><comment><USER32> If you can infer information from encrypted data then it's not properly encrypted. Generally you would use a salt that would render this type of analyses useless.

<comment><USER33> Maybe i misunderstood something, but they are not really inferring information. The model is still encrypted, the outsider doesn't know what's going on. Wouldn't salt destroy the homomorphic property?

<comment><USER32> Homomorphic encryption is malleable[1] in that it can, with enough information, be decrypted without knowing the private keys in some cases. For example, if you can correlate with other data it may be possible to effectively undo the encryption.

This is more like anonymization (effectively a one-way hash) than encryption. If you encrypt 2 different values with the same algorithm and key, you will get the same ciphertext which reveals information about the original value (i.e., that they are the same).

[1]: [https://en.wikipedia.org/wiki/Malleability_(cryptography)](https://en.wikipedia.org/wiki/Malleability_\(cryptography\))

<comment><USER34> There is no reason to reuse the same key though...

<comment><USER32> If you used a different key for each datum then you wouldn't be able to do this type of analyses.

This analyses depends on the property of the same values producing the same ciphertext, which also mean you're leaking information.

<comment><USER34> No it doesn't. The model is trained on unencrypted data. It is then run on encrypted data sent by the client to generate an encrypted classification. The client then uses its decryption key to decrypt the encrypted classification. This process is possible because the model is built to commute with encryption.</comment></comment></comment></comment></comment></comment>