Bitcoin's ASICBOOST Problem Explained [pdf] - <AUTHOR> http://rubin.io/public/pdfs/Asicboost.pdf <comment><USER3> This is excellent. I've been trying to find a technical explanation of ASCIBOOST for some time. Most of the articles and discussions gloss over the details.

It is possible that this is part of the reason some miners are blocking SegWit but there is more to it. Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This pissed a lot of people off and led to the blocking of SegWit. I don't see ASCIBOOST as a real problem for Bitcoin.

<comment><USER4> >I don't see ASCIBOOST as a real problem for Bitcoin.

It often incentivizes miners to reorder or drop transactions until they hash to a specific value. (A certain mining pool is publishing a significant number of empty blocks.) Miners exist to verify transactions, and Bitcoin was designed with transaction fees in order to incentivize miners to include transactions. A competing force pushing miners away from including transactions that can be trivially fixed is just a bug.

Imagine a mining "optimization" which involved miners making only empty blocks. That goes against why Bitcoin has mining in the first place, and would delay transactions eventually to a halt as more took advantage of the optimization. A trick that only often encourages miners to make empty blocks isn't categorically different, and it's something suboptimal about Bitcoin that can be fixed.

<comment><USER5> Reordering or dropping transactions is a non-issue. All you need to covertly implement Asicboost is dropping 2 random tx on the left side of the tree, and 2 on the right side (out of ~2000!) That's enough combinations to find enough partial merkle collisions. So at worst these 4 dropped collisions will be included in the next block because the next miner, even if he also implements Asicboost, will statistically almost certainly drop 4 different collisions.

And it's not true that a "significant" number of blocks are empty. Only ~2% of them are.

Furthermore the reason some blocks are empty is not due to Asicboost. It's because after a new block is found, there is a small delay until a miner can assemble the new set of txs, and during this period of time the hardware has to mine on _something_ (empty block).

Above all, it would be in an Asicboost miner's interest to include as many tx as possible in order to gain a ~10% increase in revenues from tx fees!

So, no, I disagree that Asicboost is a "problem". It's not. It looks like Gregory Maxwell either misunderstands/misanalyzed the "risks" or is simply dramatizing the situation for his own personal (political) reasons which would be part of his plan (Blockstream's plan?) to attack and discredit large-scale miners in the overall debate of Segwit vs. Bitcoin Unlimited.

Asicboost could hypothetically become a problem only if (a) mining profit margins became very thin caused for example by a multi years period of BTC losing value or remaining flat, (b) if somehow the 3 Asicboost patents (Bitmain's, KnC's, Hanke's) were never licensed to anyone else, (c) if the patents owners actually did evil things by abusing their patent rights, and (d) while all this chaos is happening everyone else sits on their hands instead of ignoring the patent and adding the optimization to their ASICs for the benefit of Bitcoin's health or survival if it came to that...

It's very unlikely that (a) (b) (c) (d) all occur at the same time.

<comment><USER5> Hah! There is actually a 4th patent for asicboost: [https://medium.com/@vcorem/the-real-savings-from- asicboost-t...](https://medium.com/@vcorem/the-real-savings-from-asicboost-to- bitmaintech-ff265c2d305b)

4 patents (applications) from 4 different holders! This provides enough competing interests that it is even less likely that asicboost will ever turn out to be a "problem".

</comment></comment></comment></comment><comment><USER6> Just to point out that SegWit is everything but "already adopted in the industry". It turns out that SegWit is the solution promoted by the developers of bitcoin core to allow for bigger blocks, and solve some issues like transactions maleability. It's more than 10 000 lines of code highly controversial because they require... A soft fork, and will change bitcoin in a fundamental ways.

Not to add that a company called "Blockstream" have paid almost every developers of bitcoin core to push Segwit without a clear consensus from the community. Worse, this company actually support the huge censorship happening in bitcointalk and r/bitcoin. Blockstream received more than 75 millions from AXA, for obscure reasons.

The paper only focus on Segwit, without mentioning that Segwit has nothing to do with ASICBOOST. The community and a growing majority of miners is actually switching to bitcoin unlimited, a fork of bitcoin core.

Sorry for the little off topic comment but I love Bitcoin and I hate that a few dishonest people took control of it and try to destroy it.

<comment><USER7> I want to say that I've been on the anti-censorship boat and the 'AXA money is sketchy' and the unlimited train for as long as I've heard of it.

Just recently, someone in the ecosystem that I've known since the beginning of my time with Bitcoin came out in support of Blockstream and Segwit with a backing of other Canadian support.

[https://medium.com/@francispouliot/canadian-bitcoin- economic...](https://medium.com/@francispouliot/canadian-bitcoin-economic- nodes-unite-against-bitcoin-unlimited-412786fb4bb6)

I don't know what to make of it all. I spoke with him a bit and he seems to believe that those pushing against segwit are paid by ASICboosters in China because they stand to make $100,000,000/yearly from their (now not so secret) advantage.

In any case, I just wanted to add that I'm more confused than ever and things are very unclear.

<comment><USER4> >because they stand to make $100,000,000/yearly from their (now not so secret) advantage.

If anyone is confused how the 30% advantage that ASICBOOST gives translates into this huge number, remember that the 30% boost applies to revenue, not profit.

The revenue of mining in the long run approaches the costs to mine (basically the cost of electricity), leaving extremely slim profit margins. Let's say the usual revenue from mining over some period of time is $1.02, and the cost is $1.00, giving a profit of 2 cents every time unit. A miner using ASICBOOST could have a revenue of $1.32 every time unit, giving a profit of 32 cents every time unit, which is at least an order of magnitude more profit than anyone else. This miner then has more resources to spend on buying hardware and scaling up.

(The above paragraph goes for any type of optimization and isn't necessarily nefarious. It can be a problem if one miner effectively keeps an optimization secret for too long, because they'll continue to grow in size and could get more than 50% of mining power, which is a specific point that causes huge problems with Bitcoin. But the real unique issues about ASICBOOST are about how it encourages empty blocks, and how it has been secretly incentivizing some groups to argue against any incompatible protocol change.)

<comment><USER8> Your arithmetic is off. Revenue doesn't increase. Costs decrease. Effectively the increase in profit is similar, though, to your _result._ Just for different reasons.

Ignoring depreciation or hardware costs, the arithmetic is like this:

Pre-ASICBoost: Revenue: $1.02 Costs: $1.00 Profit: $0.02

Post-ASICBoost: Revenue: $1.02 Costs: $0.70 Profit: $0.32

The closer to costs that revenue for non-AB mining is, the closer to infinity the comparative profit margin is.

That is, AB doesn't increase hashrate. (That would be a very, very much more complicated equation since the hashrate reward pie is essentially static.) All it does is decrease _the amount of power required to do the same work_.

</comment></comment></comment></comment><comment><USER9> This might not be the place for this question, but can someone explain why we can't / shouldn't have _both_ unlimited block sizes and SegWit?

Block sizes will supposedly be constrained by bandwidth / propagation times. SegWit will allow more transactions to occur off chain, reducing the need for larger blocks.

They seem complementary to me.

<comment><USER10> SegWit does in fact represent a block size increase. It results in 1.7x the # of single-signature transactions per block and 4x the # of multi-signature transactions per block.

Unlimited block size? There are many reasons that's a very bad idea but here are a few:

1\. It would put immense pressure on the network in terms of latency between miners, leading to less stable mining, a higher rate of reorganizations, and a massive advantage for the larger miners, resulting in increased mining centralization.

2\. It would result in a substantial increase in the amount of bandwidth that each node has to handle. Modest increases are OK but unlimited blocks means the vast majority of nodes will die off. Remember that nodes have to check blocks as they come in, so this would be an insane DDoS vector. Imagine putting a funnel in someone's mouth instead of a straw and being able to force whatever you want in there.

3\. It would result in a substantial increase in the amount of data that each node has to store. Remember that in Bitcoin 100% of data must be stored by 100% of nodes. Imagine "unlimited emails" with Gmail meant that you had to store all of the emails in the world for EVERYONE. Not a good idea.

<comment><USER11> That's not an increase in the size of the block per se, as much as it is an increase in the efficiency of encoding off-Blockchain information, no?

<comment><AUTHOR> No, it is a space increase! Witness data is counted with a discount. Blocks can be larger than 1MB under SegWit.

<comment><USER11> Perhaps this is semantic?

<comment><AUTHOR> It's not semantic, it is substantive. A maximally utilized SegWit block is larger than a maximally utilized current block.

I.e., if you were planning out how much disk space you needed years in advance, you would have to increase that figure non-negligibly if SegWit activates.

</comment></comment></comment></comment></comment></comment><comment><USER12> Some context: [http://hackingdistributed.com/2017/04/05/bitcoin-drama- respo...](http://hackingdistributed.com/2017/04/05/bitcoin-drama-response/)

<comment><USER4> I find this article very misleading.

>2\. If ASICBOOST was actually used, we'd see ample evidence on the blockchain.

The covert form of ASICBOOST (where they don't use the version field, the form that was only recently publicly discovered) would only show up as a higher than usual number of empty blocks or blocks with reordered or missing transactions (depending on how the attacker implemented it; it's not necessarily both).

>3\. ... As you can also examine for yourself, the transactions are ordered essentially by fee-per-byte, which is not what we would see if they were shuffled to create collisions.

I find it extremely disingenuous that the author only focuses on looking for reordered transactions and ignores the often-noticed unusual number of empty blocks that Antpool mines[0], and the article reaches absurdity when the author claims that the lack of reordered transactions means there's absolutely nothing to worry about.

>4\. Building more efficient mining chips is what miners are supposed to do, as it secures the blockchain. Framing an optimization as an attack is disingenuous. Going from 28nm to 16nm was not an attack on the network. Better mining algorithms have never been considered an attack.

If for example a mining "optimization" encouraged every miner to mine only empty blocks, then calling it an attack doesn't sound out of place. An optimization that only often encourages miners to make empty blocks isn't categorically different.

>7\. Segwit is being offered as a solution to ASICBOOST. Yet Segwit has at best a tenuous connection as a response to ASICBOOST mining. There are countless other, non-controversial solutions that can disable ASICBOOST, should one choose (wrongly) to do so.

Greg Maxwell's very post announcing the issue introduces a fix for the covert form of ASICBOOST that does not involve implementing SegWit!

[0] [https://bitcoin.stackexchange.com/questions/50184/why- does-a...](https://bitcoin.stackexchange.com/questions/50184/why-does-antpool- mine-so-many-empty-blocks) [http://www.livebitcoinnews.com/antpool-generating- large-amou...](http://www.livebitcoinnews.com/antpool-generating-large-amount- empty-bitcoin-blocks/)

<comment><USER13> Either I am crazy and don't understand bitcoin or some well funded group is spending a lot of money to support SegWit and push Core's agenda.

The few sensible posts like yours are downvoted to hell and back while pro- SegWit rocket to the top. Every point you make is spot on and there is no sensible reply to any of them, just a bunch of garbage about no one supports BU and BU will never happen...

<comment><USER4> I'm not really sure you replied to the right post, or you might be mixing up some things.

The hackingdistributed article I was criticizing was framing Greg Maxwell as making up the whole ASICBOOST attack as pro-SegWit propaganda. There seems to be a group that's extremely anti-SegWit that thinks that the ASICBOOST news is made up to push SegWit through, and the article is following that pattern.

I wouldn't necessarily call my criticisms "pro-SegWit", but it's definitely not on the mentioned anti-SegWit "side" if someone were to group things by side.

>or some well funded group is spending a lot of money to support SegWit and push Core's agenda.

The operator of Antpool has been one of the people speaking out against SegWit, and it's just been revealed that he most likely has had a huge secret monetary incentive against SegWit and not for the good of the network.

</comment></comment></comment></comment><comment><USER14> Anything that makes mining empty blocks more profitable is bad. Empty blocks are an attack on the network. Someone is going to say "Empty blocks give people a reason to raise fees." DDOS attacks give people reasons to buy more expensive routers too.

</comment><comment><USER15> I genuinely believe most of the comments on this page are paid trolls. Which I didn't think was a thing on HN

People should read up of the Chinese miners disinformation campaign. Really crazy stuff. [https://medium.com/@WhalePanda/the-extended-extension- block-...](https://medium.com/@WhalePanda/the-extended-extension-block- story-5bc3d888bdde)

</comment><comment><USER16> Besides the technical issues involved here, there's been a lot of political quarrels as well. Here's my run down of them. Note that I was heavily involved in the Bitcoin community a few years ago, but have been on the side lines recently. As with all things political, take my interpretations with a grain of salt:

1) The Bitcoin network began experiencing congestion due to rise in popularity driving large numbers of transactions. This resulted in slower transaction verification and higher transaction fees.

2) Users started asking for larger blocks, so that the network would have higher transaction bandwidth. The defacto Bitcoin developers at the time pushed back. Increasing block size is simple in terms of code change, but requires a risky hard fork. It's also only a temporary fix. Bitcoin will grow and require another increase, and thus another hard fork. They wanted a better, long term solution.

3) After a lot of discussion the developers came back with Segregated Witness. It's a soft modification to Bitcoin which meant no hard fork. It doesn't explicitly allow larger blocks. It does, however, upgrade Bitcoin to allow side chains. The argument is that faster, more abundant transactions can be implemented in a side chain system. A sort of second layer on top of Bitcoin. Much like how HTTP is implemented on top of the underlying TCP/IP protocol.

It should be noted that, while this enablement of side chains is the biggest feature of SegWit, there were a few smaller improvements. It _does_ increase effective block size slightly; ~2x. And it fixes a few minor annoyances in the Bitcoin protocol (e.g. malleability).

4) The community was disappointed by the lack of larger blocks. While developers were busy putting together their idea and specification for SegWit, the congestion issues on the network continued to grow worse.

5) Eventually the debate became "on-chain" versus "off-chain". Some of the community argued that they wanted to keep all transaction on the Bitcoin blockchain. In other words, they still wanted bigger and bigger blocks. I believe the root of this argument is that Bitcoin has served us well for many years, so why try to build another, potentially weaker system on top of it?

The other parts of the community were in favor of SegWit and off-chain transactions. Side chains would allow for faster transactions and significantly more of them, and they would consume far less disk space (a growing concern in the community is the disk space required to run a Bitcoin node). Side chains achieve this by compromising on some of the strengths of Bitcoin, either by reducing security or requiring more centralization.

6) Eventually the debate in the community shifted from just on-chain versus off-chain to SegWit versus bigger blocks. Now, to be clear, SegWit doesn't preclude the possibility of larger blocks. Obviously larger blocks can be added regardless of SegWit. But, for whatever reason, the dialog shifted.

7) When SegWit was finally released as part of the Bitcoin Core client (the defacto standard for Bitcoin clients/wallets) a sort of battle amongst the community began. Mining operations that ran the SegWit enabled clients started getting attacked; DDOS, etc. There was a lot of strife, hate, and fear. The way SegWit is implemented in the code, it requires a large majority of miners to support it before it officially activates and can be used. This is by design, to ensure the community agrees with the feature and to ensure almost all miners are able to understand the new blocks and not get left behind after activation. Because of this majority requirement, the battle in the community and between miners was very important. If half the miners didn't agree with SegWit, it would never activate.

8) This "battle" went on for a long time and is, currently, still on-going. Bitcoin continues to remain congested. Transaction fees have continued to rise. SegWit is still not activated. During this time a couple factions of the anti-SegWit community split off in attempts to fork Bitcoin. They modified versions of the Bitcoin client to enable larger blocks. So far, none of those forks have been successful, in terms of taking away any majority of users from the main Bitcoin network.

9) Recently it became public that a large mining operation may have been using a technology called ASICBOOST during this time. It allows mining chips to be more efficient, which means those chips make more Bitcoins for less money. Obviously an advantage. This technology has been known about for awhile now, but as far as the community knew no one was using it. It was covered by patents, and there's a sort of gentleman's agreement in the community not to use it as a result of the patent and potential ill effects on the network. (The patent means not all miners would be able to use it, so it presents an unfair playing field).

ASICBOOST, the way this mining operation has supposedly been using it, is not compatible with SegWit. That's explained in the OP.

The accused mining operation was also involved in a lot of the anti-SegWit activity in the community; promoting the alternative forks of Bitcoin. They had been accused in the past of using sock puppets to drive anti-SegWit agendas, drive character assassinations, etc.

They are in control of a large percentage of the total Bitcoin mining power.

The public revelation of them using ASICBOOST painted a dark, but enlightening picture.

As I mentioned before, SegWit ultimately has nothing to do with the on-chain versus off-chain debate. It merely _enables_ off-chain possibilities. It doesn't force them. So it was odd to see the discussion shift from on-chain versus off-chain to SegWit versus Bigger Blocks. The theory now, given the accusations against this large mining operation, is that they are responsible for the majority of the anti-SegWit movement. Because the activation of SegWit would force them to stop using ASICBOOST the way they've been using it, it was in their financial interest to prevent SegWit from activating.

That's basically my summary of events.

I think that theory, that this mining operation has been basically using anti- SegWit propaganda and other attacks to prevent SegWit from activating, so they can keep using their secret version of ASICBOOST and profit (to the tune of $100 million a year), makes a lot of sense. Why else would anyone oppose SegWit? I've read through the SegWit specs. It enables a lot of really cool tech for Bitcoin. Side chains are not just about trying to get more, faster transactions into the Bitcoin network. They're also about allowing other technologies like smart contracts to tie themselves in Bitcoin.

You know all those cool features that various alt coins are testing out? SegWit enables those features to become side chains so that you can gain all the security that Bitcoin offers. Side chain versus altcoin is like browser addon versus a whole new browser.

At the end of the day, people in favor of bigger blocks could still campaign for bigger blocks. SegWit doesn't prevent that. A mining operation being financially incentivized to block SegWit is the simplest explanation I've heard yet for why there would be significant opposition to it.

<comment><USER17> Hey, the big reason to oppose segwit is mostly as a negotiation tactic.

Many of the bitcoin developers , small blockers, and the blockstream people really, REALLY want segwit to activate.

They are so desperate to have it, that although they may not explicitly agree to a "compromise" 2MB HF + segwit proposal, they might at the very least not go freaking nuclear or something in their attempts to oppose it.

Segwit is nice, sure. But us big blockers know that if it gets activated now, then we are never going to see big blocks, regardless of how much support we get.

Don't believe me? Just check out some of the stuff that lukejr (the lead bitcoin developer) says.

They explicitly say that it could be decades before any more block size increases come around.

<comment><USER16> I'm happy to have some big blocker perspective, as I know my comment perhaps paints "Big Blockers" in less than favorable light. Not intentionally. It's a bit hard to be completely fair in a short summary, given the events that have occurred, even though those events are likely not the fault of real big blockers.

That said, good technology should _never_ be used as a bartering chip.

I think it's hypocritical of any Bitcoin user to be against SegWit for political reasons. From day 1 Bitcoin has suffered of accusations of being used for illegal and evil activities. And from day 1 we, as a community, have had to fend off those claims saying "Yes, it _can_ be used for illegal activities. But that's not what it's about. It's about a revolutionary technology that, for the most part, will be used for good."

To block SegWit is to go against that ethos, an ethos so embedded into Bitcoin. It's about technology; about changing the world. SegWit enables so many cool new uses for Bitcoin. Can it be used to create off-chain transactions; something some big blockers are against? Sure. But that's no reason to stop good technology. Just like it was no reason to stop Bitcoin itself, just because it _could_ be used for illegal activities.

> 2MB HF + segwit proposal

I don't understand that proposal at all. SegWit _is_ an increase in block size, by on average 2MB. So why have the additional hard fork if the block size is already increasing?

> Segwit is nice, sure. But us big blockers know that if it gets activated > now, then we are never going to see big blocks, regardless of how much > support we get.

The one good thing to come out of this years long battle in the community, is that ultimately users and miners are in charge. If big blockers wanted big blocks, all they have to do is offer them. Offer real specifications and real code with real tests and real study. To date, I've never seen that from the big blocker camp.

I'm not in either camp, really. Small or big. Personally, I think Bitcoin will need to increase block size eventually anyway, whether directly or indirectly. 1MB forever is silly. But nobody has offered a reasonable, long term solution to increasing block size, besides SegWit. Hard forking is very risky. Emergent consensus is risky.

All the big block supporting altcoins I've seen are cobbled together messes. And I'm not speaking as a user; I'm speaking as someone who writes code for a living, implemented the foundation of all modern mining ASICs, and have dealt with the Bitcoin Core code specifically as well.

<comment><USER17> 2MB HF + segwit (2MB average) adds up to 4 MB total. 4MB forever is better than 2Mb forever.

If this whole debate really is because of soft fork is hardfork, that is easy to solve.

You can scale by soft forking using extension blocks, OR just by changing the segwit discount parameter that segwit does.

If segwit can do it, then so can 4MB segwit.

</comment></comment></comment></comment><comment><USER18> Wasn't the entire point of picking SHA-256 to both check the integrity of the existing ledger (why it's a hash) AND as a proof of work lottery?

The "problem" being that instead of being a proof of actual work, shortcuts in the work were found.

It seems then that a good solution would be to force many different types of proof of work. Different basis of hashes are obvious, but maybe some type of actual work every so often as well.

<comment><USER19> > The "problem" being that instead of being a proof of actual work, shortcuts > in the work were found.

The same "problem" occurred when people invented GPU mining, then FPGA mining, then ASIC mining. As long as SHA256 isn't broken, it doesn't matter what kind of speedup miners manage to get; whenever someone finds a big advantage, everyone else uses it soon enough.

> Different basis of hashes are obvious

"Use more hash functions" is sort of a reflexive response you get a lot from non-cryptographers, but the intuitive reason this is a bad idea is that if your hash function isn't broken, your cryptosystem shouldn't be either. It's better to fix the cryptosystem than to half-assedly patch it over by obfuscating any problems with more hash functions.

> but maybe some type of actual work every so often as well.

What do you mean by "actual work"? In all likelihood, whatever you're thinking of has none of the properties that make PoW a viable mechanism for sybil resistance.

<comment><USER20> > everyone else uses it soon enough.

Unfortunately in this case, ASICBOOST is both patented, and adds a fair bit of complexity to mining hardware. Both these problems have the undesirable effect of increasing the barriers to entry for new asic manufacturers - <USER2> undesirable thing from the point of view of Bitcoin users.

You're quite correct that shortcuts are irrelevant, but the reality of manufacturing makes the playing field a lot less level than we'd like.

<comment><USER10> Exactly, I'd go further and say that if a particular technique is patented and cannot be matched by a related technique, giving a permanent unfair advantage, it is up to the community to change the proof of work and work around the advantage imposed by a state monopoly.

<comment><USER3> Then Bitcoin has to hard fork every time someone comes up with a new patentable idea. I don't see why people think mining must be fair. It only has to not become completely centralized.

<comment><USER21> Someone who can control the majority of the hashrate can enforce a transaction whitelist. Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.

<comment><USER8> > Bitcoin's independence from the state requires the world superpowers are not > able to control a majority of the hashrate.

Too late. :-)</comment></comment></comment></comment></comment></comment></comment>


The Creepy Details of Facebook's New Graph Search - <AUTHOR> https://www.eff.org/deeplinks/2013/01/facebooks-graph-search <comment> brown9-2 _This feature has rolled everyone, by default, into a dating service ("Single females in San Francisco who like Radiohead") and a marketing database ("People under 25 who like Coca-Cola")._

This assumes that the advertisers didn't have access to searches like this already. That seems very unlikely.

<comment><USER2> Did they have access to this, or did they have access to "show my ad to everyone who matches this query" ?

I don't see why Facebook would allow advertisers to build databases of people when they can just force them to go through their own tool and keep people anonymous, like Google does.

Also, this is free, as opposed to advertising tools, which broadens the audience quite a lot.

<comment><USER3> I don't think they have access to that, and you are right, there's a big difference between getting search results with actual people links, and getting your ad anonymously delivered to people matching a given criteria.

By the way, you can click through the "create an ad" process quite far on facebook before you have to actually pay for it, so for those curious, why not give it a go and see for yourself what the process looks like? :)

</comment></comment></comment><comment><USER4> I personally think this feature is really cool, and has the capacity to be really useful. While I don't personally mind people creeping me, it _will_ likely have vast social implications.

For example: <https://dl.dropbox.com/u/46245195/jealousy-machine.jpg>

</comment><comment><USER5> Seems to me like Facebook was already using these "creepy details" on a daily basis in targeted advertisements. I looked through the ad process, and you could choose any of the options they have in the article (age range, likes, location, etc.)

<comment><USER6> I think it's quite different for a company to use "creepy details" to deliver targeting advertising than it is to make that information available to the public in an easily discoverable fashion.

Graph Search is really interesting from a data standpoint, but I don't at all see how it's going to mesh with the realities of how people like their data to be managed.

<comment><USER7> How can you feel about clicking on an Ad that matches one interest of yours if you don't know the additional targeting criteria?

The more specific the criteria, the more likely the "advertiser" is a spear fisher.

I can think of a couple exploits (Err- links) one might pay to send to "groups" like: All Oracle employees who like sailboats and tennis. All Universal Health Care employees who like Oracle. All apple employees who hate google maps.

The total cost of these 3 "campaigns" might be $30. You may hit these targets with a wider google campaign, but that would cost more and entail greater risk (i.e. people at mcafee who like nmap and Oracle.)

<comment><USER6> Do advertisers get information on the specific users who click on their ads? Can you reverse-map an ad click into a Facebook profile?

<comment><USER8> No, this isn't possible.

<comment><USER6> I get the "technically possible" argument above, but this is what I'm driving at - targeted advertising is one-way (you can target people, but don't know who they are), while Graph Search is two way (you can target people, and find out who they are), which is why I don't think the comparison between the two is all that apt.

</comment></comment></comment></comment></comment></comment><comment><USER9> This at least exposes what you could have been doing all along using their API. If anything it is better that they launch this and people realize the implications rather than developers being able to do it without people really understanding the implications.

<comment><USER10> And how the law will use it. Seems like a great way to find criminals and activists at scale

<comment><USER11> I find it creepy that our impression of the government now has us lumping criminals and activists into the same sentence and thought.

</comment></comment></comment><comment><USER12> Privacy and utility are mutually exclusive, privacy and utility are mutually exclusive.

This can't be said often enough.

I personally hate Facebook because of Zuckerberg's disregard for Steve Jobs's definition of privacy: to know what you've signed up for.

But there's definitely a lot of utility for those who willingly hand over their personal information. It's a trade-off, and I'm fine with it, as long as people knowingly, willingly accept that.

</comment><comment><USER13> I really like it. The constantly increasing social pervasiveness is inevitable and I've made my peace with it a long time ago.

I understand why it took them this long to come out with something like this. For this to work, you need massive amounts of data, something Facebook has plenty of after receiving a firehose of data for so many years.

Google has failed in social search, because (ironically) they had the search first, but not the data. IMHO this is exactly what they were afraid of and the main reason why they keep pushing on G+ hard.

Most importantly, Graph Search finally "captures the intent" - which made Adwords so good - that FB Ads was badly missing. Expect to see their revenues soaring in the coming years.

<comment><USER14> _> Google has failed_

You say that as if the competition was a specific event with a discrete ending time, rather than continuously ongoing process that ever ends.

</comment></comment><comment><USER15> Wasn't it Assange that said fb was the greatest spying machine ever invented? Why the heck people will continuously give away private information with no safeguard that information will ever remain private in the future, I will never understand. Graph Search is just one more example of 'transparency creep' until there is only a microcosm of privacy left, and even that will likely be an illusion.

<comment><USER16> > Why the heck people will continuously give away private information with no > safeguard that information will ever remain private in the future, I will > never understand

I do understand. People don't evaluate risk correctly. They are fundamentally irrational in all sorts of strange ways. Humans have a strong optimism bias[1] so even if they know something bad might happen to some people they __know __that will happen to other people, not to them. The benefit, even when it's tiny in comparison, they get _right now_.

Thanks to the fascinating new neuroscience around cognitive biases you too can go from thinking you'll never understand to despairing for the future of humanity!

At least now someone will probably do a Firesheep-esque [2] "look how creepy you can be" app that will get some attention. And that kind of attention is exactly the antidote to the optimism bias as well as many of the others at play here, it's actually very effective because it plays into other well known biases [3][4]

[1] <http://en.wikipedia.org/wiki/Optimism_bias>

[2] <http://codebutler.com/firesheep/>

[3] <http://en.wikipedia.org/wiki/Attentional_bias>

[4] <http://en.wikipedia.org/wiki/Availability_heuristic>

</comment></comment><comment><USER17> Think about what this will do for discriminatory hiring. Searches on who has liked political statements or views that are disapproved of by corporate policy. Again as others have state - big difference between this stuff being discoverable and it being easily searched, sliced and diced.

<comment><USER16> What's the big difference other than smaller players having access to this information?

Maybe I'm going to far applying computer security concepts to real life but this was possible before, so making it easier to access only really changes how educated the users are about over-sharing. I mean, if you wanted to educate people in a "wow that's creepy" way like firesheep did you would build something like this.

If you shared it online and it's linked to your real name then you _have_ to assume anyone can get a hold of it.

In the practical world you make an excellent point about discriminatory hiring, but I feel like this was going to happen anyway so better to open things up now and hopefully scare people into realizing what they are doing when they post private information publicly. The longer the time until this happens, the worse it will be when it does right?

<comment><USER17> I think this is a classic example of where there's a meaningful difference between possible and really easy. To use a topical analogy. People in the UK can do a mass-killing, with knives or clubs. People in the US can do it a whole lot easier because they have access to high powered firearms.

<comment><USER16> I see what you mean, but I don't think your analogy fits. People are only vulnerable if they choose to be and it's not the difference between knives and firearms, it's the difference between the powerful with firearms and everyone with firearms.

I think my Firesheep comparison was better. Firesheep made something possible easy and the result was not an outbreak of hijacked email and social media accounts although that certainly happened in cases where it wouldn't have otherwise. The result was education through surprise and an actual improvement in online security practices (defaulting to https).

If someone is going to have this level of information more transparency about what there is and what can be done with it is the lesser of two evils.

</comment></comment></comment></comment><comment><USER18> One thing you should know is, the search has become more easy rather than typing some name in search and selecting "education,location,workplace". SO, the search i believe has now been turned out more like ruby syntax.

</comment><comment><USER19> Just so I understand this correct, if everyone is only sharing things explicitly with friends or friends of friends, doesn't that render the open social graph search useless?

<comment><USER20> A lot of the information this searches can't actually be locked down by privacy settings anymore, as far as I can tell. Facebook made most profile information public for everyone whether they wanted that or not.</comment></comment>


The Hitchhikers Guide to the Galaxy (original 1978 radio series) - chestnut-tree http://www.bbc.co.uk/programmes/b007jlzj <comment><AUTHOR> I shall go an have a re-listen to this! Many decades ago, I had the CD boxed set of the radio series, and we used to play it as the 'on hold' music on our office phone system.

Most customers would ask us what the hell they were listening to when they came off hold, whereas a few would demand to be put BACK on hold again so they could finish listening to that part.

Sadly, one day some creep broke into our office at night - about the only thing they took was the CD player next to the receiption desk that played the on hold stuff, along with HALF the collection of HHGTTG. We found one CD smashed in the stairwell of the building.

I wonder if there is a way to covertly download the BBC stream so that I can enjoy the series in its entirety again in the future...</comment>


HTML5 Fluid Simulation in WebGL - <AUTHOR> https://haxiomic.github.io/GPU-Fluid-Experiments/html5/?q=UltraHigh <comment><USER2> Previous discussion from 37 days ago:

[https://news.ycombinator.com/item?id=8325700](https://news.ycombinator.com/item?id=8325700)

</comment><comment><USER3> Beautiful.

I also find this a good test of Apple's bold claims about the speed increase in the latest version of Safari - and, true to what they say, it does seem smoother in Safari, at ultra-high, than in Chrome.

<comment><USER4> Well not in my safari. It crashes as soon as I try to click on the particles.

</comment></comment><comment><USER5> Though it looks awesome, It's spamming my console with WebGL errors:

        [.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (clear)
        [.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (check)
        WebGL: too many errors, no more errors will be reported to the console for this context.

<comment><USER6> I'm not getting these, what's the browser?

<comment><USER5> Chrome V38.0.2125.104 on 64-bit Ubuntu 14.04

<comment><USER7> What GPU/driver are you using?

This looks like either a driver bug or some unsupported combination of pixel formats.

Unfortunately, WebGL doesn't solve these compatibility issues that are inherent to OpenGL and running on a wide variety of hardware and drivers.

<comment><USER5> I see.

       product: 2nd Generation Core Processor Family Integrated Graphics Controller
       vendor: Intel Corporation
       driver=i915

<comment><USER7> Unfortunately, that generation of Intel GPUs is known to be quite bad in performance and having very buggy OpenGL drivers.

I don't know if that's the cause of the issue you're seeing but don't expect to run any fancy 3D on Linux with that GPU.

<comment><USER8> It is the same driver as the later Intel models. It is one of the very few drivers that are not blacklisted by Chrome on Linux, owing to its unbugginess.

<comment><USER7> I know, but that doesn't mean that there aren't bugs or missing features specific to that GPU model (hardware or software). But I can't be sure whether this particular issue is a driver bug or just an unsupported combination of pixel formats (FRAMEBUFFER_INCOMPLETE hints at that).

WebGL spec requires certain of pixel formats to be supported but either the test case is using some combination that isn't guaranteed to be supported or the driver+hw combination doesn't actually support everything required by the spec.

Intel has made huge improvements since the days of the i9xx series of GPUs. They were miserably bad from a programmer's standpoint.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Is this fake physics or real? How deep is the fluid, what methods are used etc...

Looks really neat.

<comment><USER6> It's solving the incompressible form of the Navier-Stokes equations, it's very barebones however - I've left out diffusion for example. It's possible to reduce the grid size and increase the solver iterations to have a more physically accurate simulation, but to go down that route I think there are a lot of algorithmic improvements that should be made

</comment></comment><comment><USER10> This is amazing, thank-you. I would love to see the addition/option of adding static geometric shapes. In other words this would make for an awesome wind- tunnel simulator.

<comment><USER6> This has been a common request, so I'm definitely going to be adding these features in

</comment></comment><comment><USER11> As a complete physics noob, can I mod this to work in 3D? I.e. model a concave rigid body shape, and have the fluid flow around it?

<comment><USER6> The mathematics generalizes to 3D quite easily, but the way the webgl pipeline is used in this case doesn't. It'd be easier I think to start from scratch. I recommend reading through the GPU Gem's article on the topic with code samples

[http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html](http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html)

although the physics is discussed, you don't need to follow it deeply to implement it

</comment></comment><comment><USER12> Great stuff! Kudos to George Corney (haxiomic), the creator!

Chromium 38.0.2071.0 (279972) works fine in whatever setting on a medium sized machine.

</comment><comment><USER13> It doesn't seem to do anything for me with Firefox Nightly/Yosemite on my recent rMBP. Nothing in the console, either.

<comment><USER14> Did you click and drag?

<comment><USER13> No, doh.

Still, maybe a little hint could work to improve usability in this sense?

<comment><USER15> I agree, took a while to figure out what was going on. Especially because the grid lines are so tiny with such low contrast.

</comment></comment></comment></comment><comment><USER16> These things make me genuinely happy.

<comment><USER17> Me too. Especially as it's Haxe (Actionscript 3) rendering out to JS / HTML

I'm hoping this goes more mainstream

</comment></comment><comment><USER18> Tells me "WebGL is not supported" on MBP Yosemite - Latest chrome version.

<comment><USER6> Strange! I'll look into this, what about safari?

<comment><USER19> For me, it works even smoother on Safari 8.0/Yosemite on 13" rMBP 2013.

</comment></comment></comment><comment><USER20> Chromium: "WebGL is not supported"

Firefox: laggy on UtlraLow settings

I've wanted to get behind WebGL for so long but if it can't work as well as the OpenGL ES running on my phone then I will just have to wait and see if it gets any better.

<comment><USER21> That odd - it works fluidly (!) on High setting on my mid 2010 Mac Mini running 10.10 and using Firefox 33, and pretty well on Ultra High setting.

<comment><USER20> I get about 2-3 FPS on Firefox 33 for Linux. Could be the Nouveau driver. The Nvidia driver slows down Firefox so I can't switch back.

<comment><USER22> How would a kernel driver slow down a browser? And nvidia runs incredibly smooth on Linux, even on older hardware.

<comment><USER20> Beats me. I've filed issues with both Firefox[1] and Gnome[2].

1\. [https://bugzilla.mozilla.org/show_bug.cgi?id=1065236](https://bugzilla.mozilla.org/show_bug.cgi?id=1065236)

2\. [https://bugzilla.gnome.org/show_bug.cgi?id=736669](https://bugzilla.gnome.org/show_bug.cgi?id=736669)

</comment></comment></comment></comment></comment><comment><USER23> This is really trippy/amazing looking. I love it.</comment>


Let's Build a Simple Interpreter, Part 1 (2015) - <AUTHOR> https://ruslanspivak.com/lsbasi-part1/ <comment><USER2> From the article: "If you don't know how compilers work, then you don't know how computers work."

I still don't understand how JIT compilers work, which is probably the majority of compilers that I'm using today. It seems that there aren't many resources or established textbooks for this area. I feel we're still left in the dark in this age.

<comment><USER3> A basic JIT is no different from a normal compiler. Just write output code to memory rather than to a file, and only compile each function as needed. It gets more complicated if you want to compete with the performance of V8 or something of course but the basics are the same.

<comment><USER4> It's a bit more complex than that. First a bit of clarification on terminology: it seems like everything that's compiling code at runtime is called JIT, but I don't like that definition. For a language implementation to qualify as JIT, it has to have an interpreter, a compiler and passing control between compiled and interpreted code.

This is where the complexity is, managing when to JIT compile a function and how to pass control back to the interpreted code. There are so many ways to do this, from compiling individual functions to doing a tracing JIT like luajit is.

So, yes, the compiler part of a JIT is "just" a compiler that outputs code to memory but the complexity is doing it just-in-time. Start executing code in an interpreter, find a hot path, then compile that and make the compiler emit instructions that return the control back to the interpreter when executing the hot path is done.

<comment><USER5> > For a language implementation to qualify as JIT, it has to have an > interpreter, a compiler and passing control between compiled and interpreted > code.

So you wouldn't consider the .NET framework a JIT? It never interprets any code, just compiles things as they are used.

<comment><USER6> Wait a second, I thought .NET is interpreted? I mean take C#. Isn't it compiled to IL and then run on CLR VM? And has JIT to speed it up?

EDIT: spelling

<comment><USER3> The JIT always runs - there's no interpreter, so if your need to run a method the first thing the VM does is to JIT compile it.

This has some disadvantages - you have to wait for the JIT to run and can't keep running in the interpreter while it compiles, and some advantages - it's simpler.

</comment></comment></comment></comment></comment></comment><comment><USER7> The problem I always have with this kind of article is that even though they, like this one, are often well written and clear they skip all discussion of the choice of language to implement as though this is somehow completely irrelevant to the task of creating an interpreter.

But it is not. An interpreter for a curly bracket language or Algol descendant (Algol, C, C++. C#, VB.Net, Pascal) looks quite different from one for a stack based language (the canonical one being Forth I suppose) and different again from on that uses S-expressions (Lisp, Scheme, etc.), and so on.

A simple interpreter for a stack based language can be a lot shorter than one for a block structured language

</comment><comment><USER8> Yes, this is a simple expression parser, I transpiled this tutorial to C earlier this year [0]. If by some chance you would like to build my C version, you would need two other libraries that I built too. Compilers is the most interesting CS topic for me. That and language runtimes. If I could go to grad school, that's what I would want to research.

I also emulated Python's `raw_input` function to my own C version :)

It was also a chance for me to use `setjmp` to implement exception handling in C. Take a look at this commit: [https://github.com/rmccullagh/calculator/commit/6afac5e5924b...](https://github.com/rmccullagh/calculator/commit/6afac5e5924b769e7a9f7a402d4dd86c1baead34#diff-2045016cb90d1e65d71c2407a2570927R43)

[0] [https://github.com/rmccullagh/calculator](https://github.com/rmccullagh/calculator)

</comment><comment><USER9> I've been following this tutorial recently and I've enjoyed it quite a bit. I think I understand grammars a little bit more as a result. If this style is interesting to you the author also has a series on building a web server from scratch. [https://ruslanspivak.com/lsbaws- part1/](https://ruslanspivak.com/lsbaws-part1/)

</comment><comment><USER10> Neat series. Another book to add to the recommendation list is Game Scripting Mastery which is a great text for learning to create scripting languages, compilers, and virtual machines. Don't judge it by the title, it's a gem. [https://www.amazon.com/Scripting-Mastery-Premier-Press- Devel...](https://www.amazon.com/Scripting-Mastery-Premier-Press- Development/dp/1931841578)

</comment><comment><USER11> Java version to play with:

[https://codeboard.io/projects/9288](https://codeboard.io/projects/9288)

It's interesting to see how much "overhead" static typing and language verbosity generates. But maybe there are also ways to write it more compact in Java, not sure.

</comment><comment><USER12> Previous discussion: [https://news.ycombinator.com/item?id=9718472](https://news.ycombinator.com/item?id=9718472)</comment>


We downloaded 240,000 posts from Reddit and here is what we did with it. - <AUTHOR> http://redditinsite.com/

<comment><AUTHOR> Please contact me on twitter @gdi2290 for any suggestions or feedback Sidenote: Our source code is on Github [https://github.com/gdi2290/RedditInsight](https://github.com/gdi2290/RedditInsight)</comment>


Making Chrome better on iOS - <AUTHOR> http://raphaelcaixeta.com/blog/2012/07/09/making-chrome-better-on-ios/ <comment><USER2> I like the spirit of this idea, but I don't think the code is complete. I installed Chrome but do _not_ want it to be my default browser. If apps started doing this, I'd just uninstall Chrome. A better choice would be to present a UIActionSheet asking the user which browser to use and then save that preference to the app's Settings bundle with NSUserDefaults.

<comment><USER3> That sounds much better than just defaulting to chrome if available.

That said, this is a bit too much overhead for most developers to actually implement. For instance, you would also need to create a settings bundle, so users can reset this setting if they want.

What I'd really like to see is Apple enable this at a system level. FireFox for iOS would be nice to see, and we don't want developers to have to revisit this issue if/when it comes.

<comment><USER2> It sounds like a lot of overhead, but it's really quite simple. Objective-C is a bit verbose for a Hacker News comment, so I put it up as a Github Gist: <https://gist.github.com/3080870>

As for making a Settings bundle, that's pretty easy too and you wouldn't _have_ to do it unless you wanted an easy way to let someone change their preference later.

Besides all that, I think everyone agrees with you that Apple should make it possible to do it at a system level. The simplest way to do this in my opinion would be to allow users to remove pre-installed apps if there is an alternative on the device. For instance, if I have an app that responds to "<http://> URLs, allow Safari to be removed.

<comment><USER3> I guess my point was, without a settings option to re-set this, it's an incomplete feature. It works for a very narrow scenario, but not for the vast diversity of scenarios that the real world will bring. For instance, your code has a fairly large bug... if the user sets chrome as the default, then at some later point they delete chrome, it won't open urls anymore.

I would definitely encourage you to polish up that gist into some kind of easily incorporated module (a category on UIApplication, perhaps?)... the more people who start doing this sort of thing, the more pressure there will be on Apple to enable this the "right" way.

<comment><USER2> Polishing it up as a category is a good idea; I might do that tomorrow. But yeah, the point of all this is that you can't set a default browser in iOS.

</comment></comment></comment></comment></comment><comment><USER4> > Google Chrome is nothing more than a UIWebView skin on iOS

Mobile Chrome's networking stack is the same as Desktop Chrome, providing SPDY, prefetching, etc.

<comment><USER5> "Chrome for iOS has some pretty major technical restrictions imposed by the App Store, such as the requirement to use the built-in UIWebView for rendering, no V8, and a single-process model. As a result it's been challenging to re-use critical Chromium infrastructure components.

That said, there is a lot of code we do leverage, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting, and a growing portion of content."

[https://groups.google.com/a/chromium.org/forum/?fromgroups#!...](https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium- dev/vYGxPx-tVKE)

<comment><USER6> Just wanted to say, great job on the Chrome app.

Only 2 things I don't like about it:

1) Getting at bookmarks requires too many clicks.

2) Sometimes my bookmarks get rearranged on the desktop after I use them in iOS.

Otherwise, great job. Syncing my browser history/bookmarks/passwords is great. And it feels more snappy than Safari, which I didn't think was even technically possible.

</comment></comment></comment><comment><USER7> Cydia has a tweak to change your default browser. Sorted.

iOS Chrome has greater issues.

Tab management is all whizz bang but very unintuitive.

I have used it for about a day and can it fathom how to email a link to the current page to someone.

Emailing a link to the current page is not a standard use case for desktop but it is typical on mobile.

Further: it's hard to see where to arrest the loading of a page, the progress thermometer 'blue zing' thing is very attractive but it doesnt allow any interaction.

Somehow the load new incognito tab button is nearer my fingers than the load a tab in background button. It's annoying that you'd assume I'm fapping.

I think the guys developing this app need to spend more time using other mobile browsers to get a feel for the knds of things people want to do on mobile... iOS Chrome feels like a desktop experience squeezed into 3.5 inches.

<comment><USER8> In order to email the current page, or stop a page from loading, hit the menu button to the right of the omnibar.

Email will be the 5th text row down.

Note that I do not think it is a side effect of desktop to mobile, but instead their attempt to maximise the content area.

<comment><USER7> After googling 'omnibar', I found the menu you speak of and I swear blind the option to email the page is not there...

<comment><USER8> > After googling 'omnibar', I found the menu you speak of and I swear blind > the option to email the page is not there...

Hopefully you get this - see the areas marked in red on the attached screenshot: <http://imgur.com/N2tL9>

</comment></comment></comment></comment><comment><USER9> Why not take this idea in a more comprehensive direction: a donation supported site with API to register your app as consuming specific mime-types, so any compliant app wanting a producer of emails for instance, could grab a list from this site and then ask the user which they prefer, out of those apps they have installed (since those apps would all phone home to the server and say "user email@example.com has installed app Y on device with MAC ID M".

<comment><USER10> This is a start: <http://handleopenurl.com/scheme/> Register your URL scheme there to avoid collisions and help garner support from those who want to support your app.

</comment></comment><comment><USER11> I don't think this would make Chrome better but rather make every app that uses this code pretty crummy. What would make Chrome (and iOS) better would be Apple setting up some kind of default app system for links, mail, photo editing etc. Out of very few things, Intent is something that Android still has over iOS. Plus of course Chrome would be better with some Nitro on top :)

<comment><USER12> How would it make it crummy?

<comment><USER3> I may have chrome installed, but not want it to be my default browser. That is, in fact the case on my phone.

If apps started doing this, I suppose I could just delete chrome, but as with my Mac, I like having a few different browsers installed.

<comment><USER13> On your mac, Chrome is a browser with its own render engine, and javascript engine. Thats not the case on iOS.

So, the only reaon to use Chrome on iOS, is because you like the interface better. If not, why keep it installed?

</comment></comment></comment></comment><comment><USER14> If you are using a jailbroken device, there are a few extensions that can provide this functionality. I believe the most comprehensive is by Ryan Petrich.

[http://www.lifehacker.com.au/2012/07/make-chrome-your- iphone...](http://www.lifehacker.com.au/2012/07/make-chrome-your-iphones- default-browser/)

</comment><comment><USER15> "If a user has Chrome installed, chances are they wish that it would be their default browser."

Horrible assumption. I am all for Apple stealing Android's intents. Assuming that because the user has an app installed they want it to be the default is wrong.

I think the better approach would be each app could ask the user once if they want Google Chrome to be their default browser and then store which one they should open. Sure it is more code but it will be a better user experience than forcing them to uninstall Google Chrome if they don't want it.

<comment><USER16> What's stopping the app creator from asking the user (in a settings" page) which browser s/he wants to open web pages in? Default will be Safari, unless changed explicitly

<comment><USER15> Nothing. That is another totally viable alternative.

</comment></comment></comment><comment><USER17> I have Chrome installed but don't want it as a default, this would just annoy the hell out of me.

<comment><USER18> Curious, why? You don't really need more than one browser on your phone. If you installed Chrome and haven't deleted it, one can assume it's because the person prefers Chrome. Otherwise you can just delete it after having tried it out. Or am I missing something?

It can't really even be for testing, since on iOS it's not like it's possible for Chrome to render any differently than in Safari!

<comment><USER17> My iPad has lots of rarely-used apps in it, as do most of my friends'. I haven't used Chrome enough to decide if I want to keep it or not, the mere fact that it exists shouldn't indicate preference.

</comment></comment></comment><comment><USER19> This is one the many reasons why I would never buy another iPhone if it couldn't be jailbroken. It seems weird that 'hacker news' readers aren't more excited about 'hacking' the incredible computer in their pockets.

We don't need to beg developers to support Chrome if we can just change the default browser ourselves - <http://i.imgur.com/f50Kxl.png>

Other reasons to jailbreak:

* Grooveshark - Seems to have a bigger music collection than Spotify, best $9 I spend each month.

* VLC media player

* SSH - how is that not useful?

* SBSettings

* 5 columns for Springboard icons

* Compiling and installing any open source iPhone apps

* Being able to write tweaks like this: [http://madebynathan.com/2010/12/26/ios-tweak-replace-operato...](http://madebynathan.com/2010/12/26/ios-tweak-replace-operator-with-current-prepaid-balance/)

</comment><comment><USER20> While this is an interesting idea, it is pretty useless in practice, IMO. Email is by far the app I (and I assume most others) am going to be clicking the most links from, and I'm gonna go out on a limb and say that Apple won't be changing their links to go to chrome.

If you use something like the gmail app, they (if they don't already) should probably be doing something like this.

<comment><USER21> or sparrow

</comment></comment><comment><USER22> what chrome on iOS really needs is access to the JIT. Till then, it will be much slower than safari...

<comment><USER23> That's a bit of a stretch. You shouldn't notice that much of a performance difference unless you go to the desktop version of Gizmodo or BusinessInsider. Fortunately they already have mobile versions (at least Gizmodo does).

</comment></comment><comment><USER24> Good idea to come up with a minimal implementation of intents on the caller side. Apple will probably block it if it threatens to become useful though, because that would challenge iOS Safari.

</comment><comment><USER25> I wish Apple would open up its system so the user can select her own default programs. Oh my, daydreaming.

</comment><comment><USER26> Just a heads up: the page doesn't scroll on android, so its impossible to read the whole article.

</comment><comment><USER27> Please Apple. I will downvote every person who whines about "stealing" if you just hurry up and steal Android's Intents.

<comment><USER28> Yup it's a major missing element on iOS and many iOS supporters just don't understand how great it really is...

<comment><USER29> I haven't used iOS, but as an Android user I can definitely see why they haven't implemented it yet. It's a powerful feature, but at least on Android, it's also a usability disaster.

Basically, the way it works on Android is that whenever an intent is passed for which there is no default, the user gets a dialog. The dialog will contain the applications that the user has installed for handling that intent. When there are 4+ items (eg, PDF) this can be confusing.

Then when they pick one (hopefully the one they really wanted) they check the box to make it default. So far this is confusing for some people, but they generally muddle through somewhat happily.

But there are issues... which protocols does the browser accept? Oh, http, https, and possible one or two more. So later they tap an https url and have to go through the same process again.

The next day, one of their four web browsers auto-updates from the Play store. This clears the defaults, and they have to go through the whole process again.

Seriously, the underlying concept seems solid, but the implementation is severely lacking. I hope that they (or someone) does this right in the future. I'm not entirely sure what a solid solution would look like, but I certainly don't expect Apple to copy the Android approach. It's completely incompatible with a number of their UX goals for the platform, IMO.

</comment></comment></comment><comment><USER30> Is Chrome for iOS open source? Would there be a way to add V8 back in and release it on Cydia? That may extend the lifespan of Apple products indefinitely. My iPad 1 is already deemed obsolete by Apple and will never receive another web browser update ever, which is obviously retarded. Apple seriously needs to get that giant stick out of their ass.

<comment><USER14> a) AFAIK, no (as in, it is not open source). b) The change would not just be to mess with the JavaScript engine: it would require totally replacing out the UIWebView backend they are currently using from Apple and, well, pretty much putting back Chrome. They are not rendering the HTML, Apple's UIWebView class is; it would probably be easier to just attempt to recompile/replace JavaScriptCore system wide to stub into v8. c) According to Apple (whom you may or may not believe), v8 is not actually much faster (if not slower) than Nitro right now, so you may as well just turn on Nitro in Chrome (which is easy to do on a jailbroken device).

<comment><USER31> > so you may as well just turn on Nitro in Chrome (which is easy to do on a > jailbroken device).

I know you may mean that it is easy to implement this but just checking if there already exists something which can do this. I searched Google and Cydia with no results. This definitely can be very very useful to a lot of people, esp hackers.

<comment><USER14> I believe it is just a matter of adding the "dynamic-codesigning" entitlement. I started typing up instructions for how to do it with a few shell commands, but then I ran into a limitation with my ancient version of codesign_allocate that caused me to fail. :( You should definitely be able to do it from a Mac fairly easily, however.

<comment><USER32> I'd also love any pointers for how to do this; I've been checking cydia daily waiting for a hack that does this

</comment></comment></comment></comment></comment><comment><USER33> First step to making it better might be fixing the awful scrolling. Chrome on iOS is slick but it stutters like hell when scrolling large vertical pages. Safari has no problem.

<comment><USER34> May not even be fixable, if it's just calling out to an Apple webview component.</comment></comment>


Some educators argue 2+2 can sometimes equal 5 - <AUTHOR> https://www.thecollegefix.com/some-critical-theory-scholars-argue-22-can-sometimes-equal-5/ <comment><USER2> > The woke argue objectivity and any either/or binary about truth (answers are > either true or false) are part of white supremacy.

But see, critical theory _also_ makes claims about truth that are quite binary. (Try telling them that objectivity and binary truth are _not_ part of white supremacy, or any of a number of other things that contradict their doctrine.) But that means that, by the quoted statement, critical theory is _also_ part of white supremacy.

I love using recursion on claims like the quote...

</comment><comment><USER3> Python thinks

      0.1 + 0.2 = 0.30000000000000004

I think that is bad enough.

</comment><comment><USER4> Why go as far as functions, how about 0 and 1 . One is clearly the phallus to zeros's vagina. Can you not be more binary then that?

</comment><comment><USER5> As mentioned in the website header, this is specifically a right-wing website. The comments bear this out. It's basically manufactured outrage, finding some college prof with controversial views (there's no shortage of those) and building an anti-liberal argument out of it.

<comment><USER6> On the other hand, it is folly to ignore what professors are teaching, and what universities will tolerate or promote. Even if you dislike the messenger.

<comment><USER5> It's very easy to cherry-pick one extreme statement and imply that all colleges and professors feel the same way. After all, those nasty elite liberal intellectuals are all on the Soros agenda!

<comment><USER6> Very true. But the only alternative to single examples are statistical studies and surveys. And hardly any news source limits themselves to that. So if we're going to accuse them of cherry-picking, we shouldn't stop with just this one story or website.</comment></comment></comment></comment>


Reimagining handwriting in a digital age - <AUTHOR> https://www.handwriting.io/

<comment><USER2> Do you have more handwriting styles available? It seems like there's an underlying fundamental 'template' with certain parameters getting randomized on each render.</comment>