What Have VCs Really Done for Innovation?  - <AUTHOR> http://www.techcrunch.com/2009/09/20/what-have-vcs-really-done-for-innovation/ <comment><USER2> The venture capital market is crumbling. It used to cost a lot of money to build a company, but not anymore and VCs are no longer the gatekeepers to success. Their exits are puny and most of them fail. They are hunting needles in haystacks. The supply is greater than demand. Their 2+20 scheme is too expensive. The wealthy don't need the VCs anymore and the returns they are bringing in aren't worth the risk.

This crap from the NVCA is not an isolated event. This absurd notion of a _founder visa_ is another data point in the trending decline of venture capital.

VCs are losing their power. They are struggling to keep it. They are crying out for help. They are being destroyed by scrappy startups and small funding orgs like YCombinator.

VCs are going the way of universities and print publications and even television. The barriers to entry are not what they used to be. The Internet, and tech in general, is the revolution they claimed it was to their original investors -- so revolutionary in fact that it is defeating even their own industry.

Why did they think they were immune to Moore's law. As technology costs decrease, supply increases. VCs operated on supply and demand just like every other industry. They controlled access to the supply of capital to startups and to the supply of startups for investors - but not anymore. The Founder Visa is another effort on their part to regain control of that startup market. If they can increase the supply of ventures only they can enable, then they regain power over other startups. If they can get 50% of a startup from India for $1M, why would they fund the same startup for the US that wants to give up only 20%?

Technology is changing so quickly that similar ideas are popping up all over the place. There are a multitude of ideas the vcs can fund. Look at TwitVid here a couple months ago.

All the signs are there. The question is, are VCs going to be able to create hype around another industry that actually _needs_ them or are they going to try to defend the fort like the newspapers are doing now?

The Internet might just be the biggest innovative idea since the printing press. It could be a long time until another change of this magnitude will come along. Venture Capital will always have a place in a growing society, but the opportunities are declining and the number of VC firms will decline as well.

Here are the tips for VC: Make your operations more scalable, increase diversity, fund in smaller amounts and expect less control and equity in exchange.

EDIT: I want to add that I know this is true because VC firms have approached us several times wanting to invest. Other companies in our market were funded in the millions by VCs and they are already gone. They couldn't build the kind of revenue or customer base the VCs expect, but a smaller startup like we are can easily sustain itself.

VC investment is having a negative impact on the potential success of a business because expectations are wildly out of bounds. It takes longer to make money now and the competition for the business idea is so great that investment of capital is not a differentiator like it used to be.

A VC funded startup may have more capital than we have, but we have _way_ more _time_ than they have.

<comment><USER3> this applies to internet companies, but any other business needs VCs. Sure you may code your startup in a few years on your own, but how are you going to open a factory without any outside investment?

<comment><USER4> Who isn't outsourcing to China anyway? :/

<comment><USER5> People who are outsourcing to Vietnam or the US?

</comment></comment></comment></comment><comment><USER6> Maybe the NVCA statistics are somewhat bogus, but there is a pretty compelling way to answer the question empirically: how many tech companies have made it as far as an IPO without taking money from VC funds?

Maybe the world is changing. Maybe now that it's cheaper to start startups, some will start to make it all the way to IPOs without VC funding. Obviously I would love it if a company we funded could make it to an IPO without any further dilution. But that seems like insanely wishful thinking.

<comment><USER7> _how many tech companies have made it as far as an IPO without taking money from VC funds?_

Any particular reason you are looking at an IPO as a milestone? Somehow I see the YC companies more like SAS.

<comment><USER6> It's unequivocal. You could also use a revenue threshold.

<comment><USER7> How about some combination of Revenue + Profitability?

Revenue alone doesn't help, I think Facebook crossed $300 MM but was not profitable at that point in time.

Current IPO's target revenue in the range of $50 MM (I think), pre-bubble IPO's required 4 straight quarters of revenue growth (something like that), this is a moving dynamic.

<comment><USER8> For what it's worth, my understanding is that the target these days (especially thanks to the costs of Sarbanes-Oxley compliance) is closer to $100 MM in revenue to even think about an IPO.

</comment></comment></comment></comment></comment><comment><USER9> Some of this critique is surely valid. But people are way too binary about this (vcs-suck vs. no-they-don't). You can see that in the first paragraph, where he argues that VC money wasn't essential to either Microsoft's or Google's success. I don't believe that's true in Google's case. I'm pretty sure that without VC money they wouldn't have been able to hire or scale in the way they did, and without those things they wouldn't be Google.

<comment><USER10> Oh, totally: the VCs were smart enough to see that Google was different enough that _both_ KPCB and Sequoia went in 50/50 on the first $25MM round. And Google had a totally failed monetization strategy (their intranet search appliances, of which they sold a single one, to RedHat) before Sergey and Larry capitulated to allow advertising on SERPs. Google needed the VC money to survive until AdWords finally delivered a coherent monetization strategy.

It's a little sad that someone with so much good analysis of the NVCA's overreaching had to throw in a jab so easily refutable.

<comment><USER9> I agree, it's superfluous and undermines his case.

This is interesting:

 _their intranet search appliances, of which they sold a single one, to RedHat_

I knew their appliance business wasn't that big, but is that really true? How do you know it?

<comment><USER11> It's false. I worked for a company that owned one and was not named RedHat.

</comment></comment></comment></comment><comment><USER12> VCs are clearly exaggerating their contribution but it is easy to forget that they are the only long-term investors in the current financial system. Who else will commit to eight years of involvement with an unknown entity? Do they need to restructure - yes, but their disappearance will not be good for startups.

</comment><comment><USER13> There's this confusion that VCs exist primarily to help innovative startups get off the ground. This just isn't true; they really exist to generate returns for their investors. The complaint that entrepreneurs are so underserved by VCs misses the point: a VC only needs to make a couple investments a year to meet their goals for their LPs. VCs aren't, and have never been, the gatekeepers to success -- and that's not their intention.

Yes, there's a long tail of crappy VCs that don't make money and are generally wastes of space -- but that's more an argument for less venture capital in the valley, not more, at any price point, whether it's $200k or $2 million.

</comment><comment><USER3> 81% of all programmer jobs? Man these VC guys must be smoking crack

<comment><USER14> so, not only they make all the money, they also want to be credited for all the innovation and leadership...

</comment></comment><comment><USER15> Venture capital is just the fuel that is required to keep an innovative enterprise running. Can oil industry take the credit for bringing industrial revolution? No.

Education, innovation and hardwork of entrepreneurs is what keeps the VCs alive. VCs depend on entrepreneurs not vice versa.

</comment><comment><USER16> What VCs do: Swamp ideas with money and kill off the better ideas, while continuing to lecture the rest of us about how our PPTs should be, what dress we need to wear, and how to be respectful of their time.

</comment><comment><USER17> I believe Angel Investors (not VCs) contributed a lot for innovation.

<http://paulgraham.com/angelinvesting.html>

<comment><USER10> Angel investors are now, and always have been, the engines for innovation. Bankers - the old angels - funded Henry Ford. Back in the day, you could get a loan from a bank for a new venture. You can't any more; this, more than anything, is why new innovation is so concentrated in geographic areas.

In the old days, New York banks would give money to an engineer in Detroit. Now, if you want angel money, you need to be physically near the angels. You can raise VC - follower - money from outside your area if you 1) have traction or 2) are a known quantity with a past exit. But a new team in a new market with a new idea? Get thee to the Valley or Route 128, cause that's where the angels are.

EDIT: I should say _networks_ of angels for first money in. SV and Mass have enough angels to syndicate a deal. You're restricted to sugar daddies doing $200K by themselves outside those areas (and maybe NYC). First Round led Mint, but they syndicated it in the Valley. Same deal with iSocket, where Tim Draper of DFJ led, but the deal was syndicated to angels.

And, of course, if you're Shai Agassi, you can raise a ton of money for Better Place, even though you have no experience in battery tech or distribution, because you're Shai Agassi.

<comment><USER18> The banks properly can't legally loan money to something so dangerous as a new business. FDIC could never afford to cover _that_.

<comment><USER10> The FDIC insures deposits of depositors, not loans made by banks. Loans are where banks (traditionally) make their loans, and the banks themselves bear the risk (traditionally) of those loans.

(I hate having to add the "traditionally" thanks to the insane securitization practices of the last decade. _shakes fist_ )

<comment><USER19> Sounds like what we need is _venture capital securitization!_

(I accept no responsibility if this HN comment causes the downfall of America in 20 years.)

</comment></comment></comment></comment></comment><comment><USER7> I am guessing the study didn't include YCombinator!

<comment><USER20> YCombinator is not a VC organisation.

</comment></comment><comment><USER21> The very fact of the continued existence of VCs for software technology businesses is a sad testament to the inability of the geekdom to capitalize on their knowledge. Perhaps we are unconsciously worried that we will suffer the fate of the Templars, but at least that last group of disruptive geeks managed to squeeze a few centuries on top of the Pyramid from their collective knowledge base.</comment>


Discovering a Blue Ocean Idea - <AUTHOR> https://capitalandgrowth.org/articles/720/part-3-six-paths-to-discovering-a-blue-ocean-idea.html <comment><USER2> There's a weird comformity effect where one tends to think in the same _terms_ as those around you, so you see the same issues, consider the same alternatives along the same dimensions. This can happen without you noticing it, your direct perception sublimating like a dream on waking.

There is gold, just one or two steps off the beaten track, but we can't see it, because we are on rails, only thinking in terms the track affords.

But it's not so easy to go off the rails: you can easily get disoriented and overwhelmed, and once you have found something, it's difficult to verify... and even harder to convince anyone else.

<comment><USER3> Note, too, that there's more garbage than gold off the rails. Simply going off the rails isn't enough. Thoughtful exploration, on the other hand, can be tremendously rewarding.

<comment><USER4> Note, three, that all garbage is gold under the light of a sufficiently child- like mind devoid of expectations, ideals, creeds, beliefs, biases, and stigmas.

The insane man is only insane when in a world of sane men.

<comment><USER5> Ehh. Some things are just not as useful as other things. This follows directly from the laws of nature.

All elements lighter than iron _release_ energy when they fuse together, while iron and anything heavier must _consume_ energy to fuse together.

Carbon is one of the most important elements for life due to its unique chemical properties and immense number of useful molecular arrangements.

The molecule we call water is essential to life as well, as it is incredibly effective, compared to the alternatives, at transporting materials to and from different parts of an organism (among other things [1]).

And so on...

[1] [http://www.ivyroses.com/Biology/Why-is-water-important-to- li...](http://www.ivyroses.com/Biology/Why-is-water-important-to-life.php)

</comment></comment></comment></comment><comment><USER6> Take a look what Chinese do, and their logic:

Making manufacturing business is HARD, harder, or many times harder than a yet another online service.

Growing and scaling such business is also hard, and it does not scale much downward as such (you have to fire workers, and they riot on you, storm your apartment and beat you and your familiy.)

The business is noticeably seasonal and have sharp highs and lows when it comes to consumer goods.

"The next big thing" opportunity like phones and tablets are come and go, they last a maximum of 2 "feast" years.

There are "cash crop" type products like battery banks, chargers, usb flash sticks. It makes profit all the time, but it's not that high.

In between big contracts, or when the factory is busy making products for itself in a feast year, factory owner do not shed capacity, but switch most of if to cash crop product

Then he puts together most talented engineers and gives them task to invent random stuff, and do trial run manufacturing.

Instead of setting up a brand around these new products, they are unceremoniously dumped to trade agents.

If agents will be placing a lot of repeating orders, then, more consideration will be given to such product.

That is "the complicated Chinese strategy" in 9 sentences.

</comment><comment><USER7> Be careful of blue ocean ideas though. Most of the time, the market might not exist yet. The ocean is blue because there's nothing to feed on there.

</comment><comment><USER8> The hard part isn't ideas. The hard part is finding actual problems that can be solved in a better way. As ycombinator put it: You have to "find customers with their hair on fire". Finding that kind of problem, along with a better way to solve that problem, is the key.

<comment><USER9> Exactly, execution is everything. Ideas are, at best, a head start. People tend to focus too much on the idea and not the value proposition. Remember, people will always buy a "better" life, you just have to make sure you can give it to them.

<comment><USER10> He's not even talking about execution. He's referring to understanding customers needs.

</comment></comment></comment><comment><USER11> Metaphors are easier to come by than good ideas.

</comment><comment><USER6> Chinese factories and OEMs are great at this soft of things, and they do it in a very simple way. That simple way is rather hard to adopt for companies in the West that are invested in their "core product" even if they have full realization that it is about to die.

Remember things like selfie sticks, electronic cigars, the bloody wifi lightbulbs and kettles, hoverboards, child trackers, consumer grade drones, and tons of other stuff that most people buy without giving any thought to who and how made the original product.

</comment><comment><USER12> Why fight over chewed-up turf? If you're able, focus on a greenfield hard tech idea well ahead of anyone else.

<comment><USER13> Because the turf is actually there. Focusing on something well ahead of everybody else will very often lead you nowhere.

<comment><USER14> There are numerous examples of ideas/business that were based on that ideas that came ahead of their time and lost big.

Only a few people, for example Musk, might be able to bet on some idea and (maybe) win. He might want to fly now to Mars, but this way ahead, we are nowhere of this capability.

<comment><USER15> Ahead of your time isn't just a problem of tech. Consumers won't buy into a product that they are "not ready for yet". A good example of this is CAS file systems al-la IPFS. The tech has been around for at least 35 years. plan9 had a fully functional CAS file system. But now, IPFS is finally getting traction, mostly because users are comfortable enough now with cloud-like services that they are capable of mentaly dealing with the abstraction.

</comment></comment></comment></comment><comment><USER16> I find this to be empty & impractical. If this methodology were beneficial, blue ocean businesses would be propping up like mushrooms.

I challenge anyone who's read this to propose a single blue ocean idea here

<comment><USER17> The blue ocean idea for Pavlok[1] (a wearable device habit/behavior trainer) wearable we developed came from a similar thought process. We wrote it up here: [https://old.pavlok.com/forgotten](https://old.pavlok.com/forgotten)

[1][https://pavlok.com](https://pavlok.com)

<comment><USER18> > _The blue ocean idea for Pavlok (a wearable device habit /behavior > trainer)…_

A digital rubber band is not a "blue ocean idea".

[http://articles.chicagotribune.com/1991-09-02/features/91030...](http://articles.chicagotribune.com/1991-09-02/features/9103060011_1_dear- ann-landers-rubber-band-biting)

<comment><USER17> Did you read the forgotten link I posted? The whole point is that we used already discovered concepts, with modern technology, to solve any bad habit. The market was and is wide open.

It's connecting multiple different technologies to attack a wide open market space. Think: smoking, drinking, gambling, oversleeping, getting over your ex, overspending, unhealthy eating, etc.

If that isn't blue ocean strategy then I don't know what is.

</comment></comment></comment></comment><comment><USER19> Text-only cache link: [http://webcache.googleusercontent.com/search?q=cache:5Yzj1yH...](http://webcache.googleusercontent.com/search?q=cache:5Yzj1yHEgE0J:https://capitalandgrowth.org/articles/720/part-3-six- paths-to-discovering-a-blue-ocean-idea.html&num=1&hl=en&gl=us&strip=1&vwsrc=0)</comment>


How to Make Common Lisp go Faster Than C - <AUTHOR> http://www.scribd.com/vacuum?url=http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf

<comment><AUTHOR> Oh, and sorry. I actually submitted a link to the PDF directly, but YCNews scribd it and now it's unreadable. Here is the original:

<http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf>

<comment><USER2> This is ridiculous. They should change the name back to YC News since they've decided to shill for their own investments.

</comment></comment><comment><USER3> This scribd thing is getting ridiculous. Why not make it an opt-out arrangement for submitters?

<comment><USER4> And while they're at it, they could also check for duplicate submissions: <http://news.ycombinator.com/item?id=172432>

<comment><USER5> They do check. The sequence of events here seems to be:

\- Person submits PDF article.

\- HN rewrites article to scribd link.

\- People complain about scribd link.

\- Admin manually corrects link to point directly to PDF.

\- A month later, another person submits same PDF article.

\- HN rewrites article to scribd link, but because the original article was manually corrected, the scribd link doesn't match the original article, so it doesn't register as a dupe.

<comment><USER6> I sense that there's a simple solution to this. Perhaps we could drop the automatic scribdifynig of PDF links?

<comment><USER4> I'm not sure why HN auto-posts to scridb.

If they're trying to send more traffic to that site, then we're S.O.L.

OTOH, if they're just trying to increase the number of documents in scribd's repository, then a parallel submission process would be the solution.

I.e., keep HN posts pointing to the original pdf, but also auto-submit to scribe, behind the scenes in a separate thread.

<comment><USER5> To be fair, the purpose of HN is to serve YC -- that's why we don't see ads on the site. People have suggested not scribd-ing everything before; I can only assume that the reason this has not yet happened is because the feedback we are providing is more valuable to YC than a few upset readers.

And this may well be the case: When most people have problems accessing a web page one way, they won't tell you directly; instead, they'll try to find another way to access it or give up. By providing only one way to read PDFs on a discussion board, you get access to this otherwise invisible negative feedback.

<comment><USER7> Yes, but not every idea turns out to be a good one.

Based on the unanimous jeers every time a PDF submission gets autoconverted, scribd appears not to be one of the good ones. Maybe it's time to try something else.

<comment><USER8> It isn't unanimous.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> My co-founder tried out some of the techniques in the paper on our system: "I was skeptical, probably because I've never done much performance tuning like this. But I changed (triples) to create a 2-d array of fixnums instead of the default list of lists from the select. I added the declarations. It's about 100x faster. 100!" Very nice :)

<comment><USER10> When I mentioned that it may be possible for a web startup in beta to improve the speed of their code by a factor of 1024 over no particular timescale, I was downmodded by five points ( <http://news.ycombinator.com/item?id=187692> ).

I can only advise that you shouldn't quit while you're ahead. Now that you've eliminated the most obvious performance bottlenecks, you may find that less obvious bottlenecks have emerged. Removing these could give you an additional factor of 10 improvement.

<comment><USER9> We're using the SBCL profiler on a regular basis to speed up the system whenever we find an area that feels a bit sluggish. We've made very large speed gains with only minor coding modifications.

<comment><USER10> I'm very impressed with your quantative approach. I'm also very curious about the type of modifications you're making. What proportion of changes are local changes which affect common cases, what proportion of changes are local changes which affect corner cases and what proportion of changes are architectural? Is it 70:20:10?

<comment><USER9> Thats a good question. Our workflow is to look at the profiler results, and work on the functions that are taking the most time. Sometimes we'll find a function being called far too many times for the page being viewed, so we'll look into the program logic to solve that. Our code is highly integrated, so most pages are using functions or methods common to many others, so a fix (or a bug) effects a large part of the system. The example 100x triples improvement sped up the entire system as triples are used at the core of our security and relations. This is a long winded way of saying I'm not sure what the proportions would be, a guess would be 60:10:30

</comment></comment></comment></comment></comment><comment><USER11> "While Lisp is mainly known for its basement on list processing, the Common Lisp standard features very efficient data types such as specialized arrays, structs or hash tables, _making lists almost completely obsolete_."

Uh?!?

<comment><USER12> In languages that can mutate data structures using side-effects, linked lists are rarely the best choice of data structure. Note, for example, that Python and Ruby have built-in array-based lists, but no linked lists. Similar structures are the default for lists in C++, Java, and C#.

That said, I'm pretty sure people use linked lists a lot in Common Lisp.

<comment><USER13> Memory usage and random access times are far better in arrays, but for dynamic resizing, deletion, insertion, appending, and splitting, that is, operations that deal with data structure rather than the content, lists are far superior to arrays.

I used to hand-code linked lists back when I used C/C++ heavily. They have some very significant advantages for modeling certain kinds of data.

<comment><USER12> I didn't mean to imply that linked lists aren't a useful data structure, just that arrays and array-based lists are well suited to an apparently wider range of problems.

</comment></comment></comment></comment><comment><USER14> We can hack around the scribd censorship. Everybody who aubmits a .pdf knows it will be converted into the useless scribd format. So, the original submitter needs to immediately post a comment that is the original .pdf link.

If HN scribd damage occurs on that link, then we will find other ways to route around that damage, for example, by using tinyurl.

Down with scribd!!!

<comment><USER8> .pdf != HD-DVD key

Hacker News != Digg

</comment></comment><comment><USER15> <http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf>

There is an easy work around for this. Submit the pdf link. Then comment with the pdf link. That adds one level of indirection, until pg gets around to fixing it.

This is hacker news, So I'm assuming people can use their browser and copy and paste.

      1) copy link location.
      2) paste link location in address bar.
      2) remove scribd.com crap, leaving the original pdf link.
      3) load original pdf link.</comment>


Amazon to block Phorm adverts scan  - <AUTHOR> http://news.bbc.co.uk/1/hi/technology/7999635.stm

<comment><USER2> Servers _shouldn't have to_ get involved with this.

Back when Phorm was being installed via spyware and included a rootkit, it was the end-user's job to make sure it didn't get installed. Now that ISPs are installing it, it's the government's job to tell ISPs to knock it off. It's difficult to comprehend why the UK government believes Phorm is legal: <http://news.bbc.co.uk/2/hi/technology/7998009.stm>

I understand why Amazon decided to act, but it's only a stopgap solution.

</comment><comment><USER3> You can ask for Phorm not to index your servers by following the instructions at [http://www2.bt.com/static/i/btretail/webwise/help.html#how-d...](http://www2.bt.com/static/i/btretail/webwise/help.html#how- do-i-prevent-webwise-from-scanning-my-site)

Apparently the webwise spider identifies itself as google and yahoo so adding a robots.txt wont help.

</comment><comment><USER4> Hopefully this will set a precedent and more companies like amazon will block Phorm</comment>


Hilary Mason Says Twitter's URL Wrapping Won't Have Any Effect On Bit.ly - <AUTHOR> http://www.betabeat.com/2011/10/10/hilary-mason-says-twitters-url-wrapping-wont-have-any-effect-on-bit-ly/

<comment><USER2> I think the bit.ly-esque URL shortening and tracking is going to be the next twitter "partner" to have their business consumed by Twitter.</comment>


Here are the Russian-made Facebook ads that tried to shake American politics - <AUTHOR> https://arstechnica.com/tech-policy/2018/05/here-are-the-russian-made-facebook-ads-that-tried-to-shake-american-politics/ <comment><USER2> What strikes me is that nearly all of them show signs of not having been made by native English speakers. E.g. dropping of definite article. I would have expected the Russians to have been sophisticated enough not to do that. On the other hand, maybe they were sophisticated enough to know that their intended audience wouldn't notice.

</comment><comment><USER3> As if the US isn't running psy-ops all over the world, including Russia.

Actually the US doesn't limit itself to such operations, _it uses military force to overthrow governments of other countries_.</comment>


Can I Stay with You While I Rent My Place on Airbnb? - <AUTHOR> http://canistaywithyouwhileirentmyplaceonairbnb.com/

<comment><AUTHOR> Weekend project to help ease some of the pains we've seen while frequently hosting on Airbnb.</comment>


A grim outlook on the future of browser add-ons - <AUTHOR> https://palant.info/2020/08/31/a-grim-outlook-on-the-future-of-browser-add-ons/ <comment><USER2> Mozilla employee here (albeit not on the mobile team):

Relax, everybody. Fenix is a major rewrite. It takes time to reimplement all the WebExtension APIs. Nevertheless, the intent is to eventually add support for all the APIs that make sense on mobile. (See here, for example: [https://bugzilla.mozilla.org/show_bug.cgi?id=1632626#c1](https://bugzilla.mozilla.org/show_bug.cgi?id=1632626#c1), or just scroll through the list of bugs here: [https://bugzilla.mozilla.org/buglist.cgi?product=GeckoView&c...](https://bugzilla.mozilla.org/buglist.cgi?product=GeckoView&component=Extensions&resolution=---&list_id=15396111))

If you go back and read old HN threads from the first public release of Fenix, people were afraid that the lack of extension support was a sign that Mozilla had given up on adblockers. I hope it's clear by now that's not true. (From what I recall of lunchtime conversations, back when those were a thing, the plan for extensions was "well, we're _definitely_ not shipping without uBlock Origin, and we'll see what else we can get working from there".) Similarly, the fact that parts of the WebExtension API are not currently available doesn't mean Mozilla has given up on it. It just means that things take time. (If it were easy, other mobile browsers might support add-ons!)

It takes a lot of resources to support two parallel codebases. At some point you have to rip off the band-aid. The sooner Fennec is cut loose, the more effort we can dedicate to Fenix improvements (like improving WebExtension support). The transition was always going to be a bit bumpy, but things should hopefully get better from here.

<comment><USER3> Why push out something half baked? You are essentially stabbing your users in the back, some of us _depend_ on those add-ons to get through the working day. To come into the office one day and to find your work environment irreversibly borked is not something that I find it all that easy to forgive. You have a very large responsibility to your users to _not_ mess up their workflows. Better to keep your update in-house until you are done than to push something half baked and not backwards compatible.

'a bit bumpy' doesn't begin to describe it, until this day there are many ways in which the current iteration of FireFox is behind where 56 was.

<comment><USER4> You seem to have strong views on this. Perhaps you should write an article about the hazards of pushing unwanted "upgrades" on users and degrading their experience? Then every time a story like this comes up, it could help to make your point again.

<comment><USER3> I just might ;)

Anyway, even if I did, it probably wouldn't make any difference.

<comment><USER4> Perhaps not, but I and probably many others would thank you for trying to at least raise the issue.

</comment></comment></comment></comment></comment><comment><USER5> _no technical reason why none of the other add-ons are allowed any more, it being merely a policy decision. I already verified that my add-ons can still run on Firefox for Android but aren't allowed to_

That makes me almost incoherently furious. I understand if you rebuild the foundation of a browser for better performance and that breaks all the extensions until the developers can rewrite them for the new model. I get it if one of my favorite extensions is no longer under active development and will never have a version released for the new model. But how fucking dare you gatekeep what I install on my own browser? Freedom from this walled-garden bullshit is the _only_ reason I run Firefox instead of Chrome. Google's twice as good at UI as you. They're faster, look better, and miraculously I never have to swipe five times trying to dismiss a Chrome tab.

I get that Mozilla is drowning, flailing around trying to create a future where they aren't irrelevant. This is just ugly, though.

<comment><USER6> According to some Mozilla people, this part is actually wrong and extension support is indeed not implemented completely. It's merely that I couldn't (and still cannot) find a list of outstanding issues, and everything I tried worked correctly.

<comment><USER5> I wouldn't put it past them to just be straight-up lying.

<comment><USER6> They don't. Mozilla at this stage is still a very idealistically motivated organization. Most people are trying hard to do the right thing. It's merely that real-life constrains often lead to rather suboptimal results, despite all the good intentions.

<comment><USER5> They do lie. Mozilla claimed Quantum was fundamentally incompatible with XUL extensions, despite the fact people could simply build their own Firefox Quantum from source with XUL support turned back on.

</comment></comment></comment></comment></comment><comment><USER7> Regarding browsers, I suspect the writing is on the wall. They have approached complexities rivalling full-fledged operating systems, and it seems to me that we're heading in the direction of the same few giant vendors authoring and maintaining both. Independent browsers that are not customizations of existing engines are probably on the way out. So we are going to end up with a few major browsers, tightly integrated with their maker's OS, and other broswer 'apps' are going to differentiate on niche features but employ the same few engines underneath, so they won't make a difference to the openness or lack of it for the web.

This is already the case with the sole exception of Firefox, the only truly independent browser not backed by an OS/platform vendor, and it's struggling badly precisely _because_ of that. But hopefully, it will still manage to nominally keep pace with the "living standards" and be ready to step into renewed prominence when the bigger players mess up or become too top-heavy for their own good.

<comment><USER8> Firefox is struggling due to the borderline legally liable gross mismanagement of their executive leadership. How are any of these people allowed to be in control of, sadly what was, such an important piece of the open web?

Mind blowing all of them do not resign out of shame and humiliation.

<comment><USER9> Can you give some examples of this mismanagement?

<comment><USER3> \- spending funds donated for browser support on frivolous nonsense that nobody wanted

\- not allowing for earmarking of donations for specific projects

\- breaking user trust repeatedly

\- firing a large fraction of employees the evening prior to picking up funding (or because of, hard to see cause and effect separate here), almost ensuring that everybody else who is capable will jump ship or at a minimum work on polishing up their resume.

\- moving income derived from one project to support others that can't stand alone

\- allowing a vast gap to come into existence between how the outside world sees the company vs how the company sees itself

\- chasing lofty, highbrow future goals and vague missions at the expense of squandering market share and user goodwill for existing products

\- prioritizing new and shiny (but unproven) stuff over core and mission critical stuff

Do you want me to go on?

<comment><USER10> It would be better to first add evidence to the allegations you made.

First of all, Mozilla donations never get used to fund browser development. Instead the browser is in part funded by "frivolous" projects that actually generate an income. The other major source of income is from Google web search. Firefox's dependence on this isn't ideal and has been critcised by many, hence the search for other revenue streams.

<comment><USER3> > It would be better to first add evidence to the allegations you made.

Is there anything controversial in what I wrote? If so I am not aware of it, this has all been laid out in some detail by now - repeatedly - so I don't see why the burden of providing evidence should be on me, unless you think one or more of these items are controversial or contradicting evidence already out there.

> Mozilla donations never get used to fund browser development.

Exactly. But they should be.

> Instead the browser is in part funded by "frivolous" projects that actually > generate an income.

I think the burden of proof is on you now.

> The other major source of income is from Google web search.

That is income that should 100% go to FireFox development, and never to anything else.

> Firefox's dependence on this isn't ideal and has been critcised by many, > hence the search for other revenue streams.

Donations to the Mozilla foundation are one such stream.

<comment><USER10> Mozilla (as of 2018-2019[0]) gets millions of dollars from their profitable projects.

Yes this pales in comparison to the hundreds of millions from web search partnership but then so does donations. However, significantly growing revenue from paid products and services is very possible. Whereas increasing donations by two orders of magnitude is very very unlikely.

> this has all been laid out in some detail by now

Providing a link to that would be useful.

[0]: [https://assets.mozilla.net/annualreport/2018/mozilla- fdn-201...](https://assets.mozilla.net/annualreport/2018/mozilla- fdn-2018-short-form-final-0926.pdf)

<comment><USER3> > However, significantly growing revenue from paid products and services is > very possible.

Of course it is possible, but that's called 'Accenture', not 'Mozilla'. Really, this all goes directly back to what I wrote above: Mozilla has an entirely different view of what company it wants to be from what the general public thinks it should be based on previous statements and there is no amount of creative redefinition that will solve that.

If Mozilla wants to be an ordinary software house then that's fine by me but then stop using funds pulled in through FireFox to support the rest of the org and allow FireFox to be completely independent of the foundation.

It is beyond ridiculous that an important resource like FireFox should be milked in order to start a software house that does not seem to be all that dedicated to keeping FF around for the long run.

If FF dies then Mozilla has failed, and the income from the search box alone should be enough to ensure FireFox's continued existence for a long time into the future.

That won't happen if Mozilla keeps raiding the piggy bank to cover for their mistakes, those 'millions of dollars from their profitable projects' are a drop in the proverbial bucket compared to the costs of the whole org. I'll bet you not a single sou of that effectively makes its way to FireFox due to the top heavy org structure.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Everything I love about tech is slowly being taken away, because technology is apparently too hard for the masses :(

<comment><USER12> At the same time, there's never been so much open-source software and hacker- friendly hardware available.

It's true that the average computing device is turning into an appliance (is it a bad thing?), but it also appears the options for DIY are ever-expanding.

<comment><USER11> The problem is these new DIY platforms don't have the kind of reach that mobile or even desktop computing has. Even 30 years ago you had people buying PCs by the droves for all sorts of general-purpose tasks. Raspberry Pis and such are great for a lot of niche use cases but you don't have people buying them as a GP computing platform.

<comment><USER13> Not yet.

I know of one company that has a few "desktops" that are Pi4 and I've seen loads of them powering "active terminals" \- like in-store menu and office status screens. Gotta start somewhere. Special case and move towards general case (some call it crossing the chasm)

</comment></comment></comment></comment><comment><USER14> This just seems like slippery slope logic. Most addons previously did not actually work on mobile. All the major addons that people use are available. I'm not sure why we're putting Firefox down for still being far ahead of every other mobile browser which still offers 0 addons. To put this in perspective, I can see 12k people use uBlock origin and the next most popular addon is NoScript with 3k. This really doesn't affect a lot of people.

<comment><USER15> > Most addons previously did not actually work on mobile.

I beg your pardon? Literally hundreds if not thousands of add-ons worked flawlessly on Firefox Android until a few weeks ago.

> All the major addons that people use are available

You'll need to seriously find some source for that extraordinary claim. What does "major" even mean? Who cares about "major ones" if 50% of my add-ons are missing, crippling the functionality of my browser on mobile? This claims makes no sense at all.

<comment><USER16> > You'll need to seriously find some source for that extraordinary claim. What > does "major" even mean? Who cares about "major ones" if 50% of my add-ons > are missing, crippling the functionality of my browser on mobile? This > claims makes no sense at all.

Presumably, "major" means "used by most people", and even without checking I'm quite sure that if you looks at the install numbers of old Firefox for Android Add-ons, you'll find that a very large part of those installs were of extensions that are still available.

Sure, I'd like my small Hacker News extension to be available as well, but I do care far more about uBlock and Privacy Badger being available - and judging by installs, so do loads of other people.

(Again, which is not to say that I'd like the smaller extensions to be available as well. But "the major addons that people use are available" looks like a mostly accurate claim.)

</comment></comment></comment><comment><USER17> > Particularly given that there appears to be no technical reason why none of > the other add-ons are allowed any more, it being merely a policy decision. I > already verified that my add-ons can still run on Firefox for Android but > aren't allowed to, same shouldq be true for the majority of other add-ons.

I wonder how the author did that. If it was a custom build of FF, we could rely on a fork as long as FF is open source and it supports extensions. If it is a configuration, I'll be happy to apply it to my FF.

Meanwhile I used ApkExtractor to save the APK of FF 68 on my phone (no root required) just in case I inadvertently upgrade FF on it. I already upgraded FF on my tablet and my old phone to test the UI. My take is that the new collections are good but the navigation UI is really bad. Opening new tabs, tapping the URL bar to go to a new site, forward button, they are all worse than in FF 68 and before. Hopefully they'll make them work as before.

I understand that staying on version 68 is also bad because of no security fixes. Furthermore it's possible that extension authors kill the Android version of their software. The plan is to wait for a while and see what happens.

<comment><USER6> Unfortunately, it was neither. However, I'm being told that Firefox Nightly allows you to install any add-ons, so maybe running it would be an option.

I actually used the debugging functionality to install a temporary add-on. This is a supported scenario, but it isn't exactly easy to set up.

<comment><USER18> > However, I'm being told that Firefox Nightly allows you to install any add- > ons, so maybe running it would be an option.

It doesn't – it's still at the stage of only being thought about:

[https://github.com/mozilla- mobile/fenix/issues/14034](https://github.com/mozilla- mobile/fenix/issues/14034)

<comment><USER6> Yes, I realized that. I probably misunderstood the user who reported this.

</comment></comment></comment></comment><comment><USER10> > What this text carefully avoids stating directly: that's the only nine (as > in: single-digit 9) add-ons which you will be able to install on Firefox for > Android now. After being able to use thousands of add-ons before, this feels > like a significant downgrade. Particularly given that there appears to be no > technical reason why none of the other add-ons are allowed any more, it > being merely a policy decision. I already verified that my add-ons can still > run on Firefox for Android but aren't allowed to, same should be true for > the majority of other add-ons.

There is a technical reason. They need to thoroughly test the new implementation of the APIs before they enable broader support. Just because the author did some (brief?) testing of a few more addons, it doesn't mean that the APIs themselves are production ready.

The main issue is that the new Firefox was released too early so compromises had to be made. Thoroughly testing a handful of addons is easier than thoroughly testing the entire web extension surface area.

This isn't a great situation to be in but there's no need to imagine nefarious plans to explain it.

<comment><USER19> The argument being presented would just as well support Microsoft releasing an automatic update to windows (automatically deployed to all their users) that only supported some tiny fraction of white listed applications. They then don't clearly make any promises about removing the white listing, or any timelines, but only vague statements about "ensuring a positive user experience" and "working with their application development partners".

Most people would probably see this as a Very Bad Thing, for a few reasons. First of all, if we were to take the claim that it's "to ensure stability of APIs" at face value, it would indicate a staggering lack of maturity in their decision making process around releases. Next, we shouldn't take the "API" argument as being anything representative of reality: applications people develop (or browser extensions) have always been the responsibility of the developers developing them. If there were bugs in a browser, they'd discover and work around them, or they'd have a broken extension/application. There isn't a way around that. Perfect APIs don't fix it: people write bugs into their applications/extensions/platforms all the time. Things are broken all the time. Testing has never been Mozilla's responsibility. It's always been on extension authors. There are already ways to "declare" in an extension that support of a specific version exists.

There is no competent technical reason to end up in this situation. We're only left with incompetence and malice. And it's _very_ difficult to think that the people running a popular mobile browser could be so incompetent. Though I'm sure we've all said that before about other Mozilla decisions.

<comment><USER10> The decision that lead to this was releasing the new browser before it was ready. This was done because Mozilla can't afford to be maintaining and supporting two different browsers on the same platform at the same time. This is nothing to do with extensions per se. They are just a casualty of pragmatism; given the initial decision the team had to prioritise.

Secondly, Mozilla absolutely do have a responsibility to ship APIs that work to spec. It's not up to Addon authors to fix Mozilla's bugs (and that may not even be possible depending on the nature of the bug). And of course you're assuming Addon authors would be interested in going so far out of their way to support what is a relatively small user base.

<comment><USER19> This argument is continuing to ignore the solution that's already used to handle new APIs that are unstable and might not be ready: allowing developers to opt-in to deployment on that platform via standard metadata included in apps/extensions. If there was a concern with things being unstable, that would be the first thing to go to! There's already support for similar things. Creating special whitelisting is something extra that had to be done. Given the "we have too much work" angle here, I find it hard to understand why the existing mechanisms weren't extended instead of creating a new one.

It seems very funny to say "we had to give up and release a broken browser" and in the same breath take on extra responsibility for API correctness prior to letting any one who can't convince Mozilla to whitelist them to use the APIs. And take on responsibility of maintenance of a whitelist

<comment><USER10> Who do you think people complain to when their browser doesn't work right? It doesn't matter if an addon is responsible, many people will blame the browser (or at least go to them for support). This increases the support cost and leads to a very negative perception of the browser itself. Also I'd suggest that addon authors publicly complaining about broken Firefox APIs would be a whole other headache for Mozilla.

We've been here before with desktop Firefox when the browser got a lot of flak for issues that were mainly caused by addons.

<comment><USER20> >This increases the support cost and leads to a very negative perception of the browser itself.

Their solution to that problem hasn't exactly led to a positive perception of the browser either, and it hasn't even left them the out of blaming it on anyone but themselves.

<comment><USER10> Sure. But there's no good solution here. As I said, the decision to support only one browser on Android is what lead to this. That browser isn't fully ready so all the team can do is go for the least worst option (which is admittedly a judgement call).

Besides, it would not be a good look to be blaming extension authors for Mozilla's problems. So I don't think that's a viable "out".

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Mozilla has made it very clear that they don't care about the add-on ecosystems and will throw away everything so they can be more chrome-like and provide a safe browser for users that cannot make decisions themselves.

They did it to desktop, now they've done it to mobile.

<comment><USER22> Why did they add any extensions then? I remember that Fenix didn't allow any for a while whilst they built that part of it.

</comment></comment><comment><USER23> I just installed FF on my Android phone last week. Haven't started using it yet but I'm desperate for any mobile browser that supports the equivalent of Chrome's _Quick Javascript Switcher_ extension - something that gives me one button "disable javascript for this domain".

I like using well designed webapps and I generally prefer to leave Javascript enabled. Unfortunately most content sites have become so incredibly user- hostile that the only way to read them is without Javascript. I do not care about enhanced privacy yadda yadda whatever... I just need to be able to turn off the crazy that much of the modern web has become.

I guess I'm too late? Sounds like FF is not my answer.

<comment><USER24> Brave has this. You can toggle JavaScript in the Brave menu. You can even go into preferences and change it to disable JavaScript by default and use the Brave button as a whitelist. I ran this way for years. It was great!

I recently switched to Kiwi+uBlock Origin because it has a proper night mode, but if you don't need that Brave is a good option (you can ignore/disable the crypto currency/advertisment nonsense).

</comment></comment><comment><USER25> Discussed yesterday: [https://news.ycombinator.com/item?id=24330983](https://news.ycombinator.com/item?id=24330983)

</comment><comment><USER26> Just quit FF because of this. Mobile add-ons were the only reason I used it vs Chrome.

</comment><comment><USER27> I recall back in the XPI extension days it was possible to host your extension on your own website and have Firefox offer to automagically install it as if it were from the normal add-on site. I believe Chrome also did this for a short while in the early days, too. Surely even with the severely gutted and locked down WebExtensions they have now, it would still be possible to do this again and independently provide your own add-on, or even host an alternative add-on store along the lines of what F-Droid does for Android.

You can put all the scary security warnings you want to scare off the unknowledgeable masses, but at least you'll provide some vector to allow niche users with niche requirements to add and trust a niche repository of their niche add-ons.

</comment><comment><USER28> The web browser "situation" that is lasting for the past couple of years inspired us to start working on new macOS/iOS web browser with webextensions API support. We are looking for people to alpha test it. Please email if interested.

</comment><comment><USER29> > In the past, add-ons have done little to help Mozilla achieve a breakthrough > on mobile

Are you friggin' kidding me? uBlock Origin is the only reason I've switched to Firefox on my mobile. I pledged to do the same on desktop the moment Chrome disables ad blocking extensions, but cheeky bastards are only threating that for years yet.

</comment><comment><USER30> Anyone know how well desktop Firefox works on mobile devices? I'm thinking situations like Debian on PinePhone or Librem 5.

</comment><comment><USER31> Seems that autofill (for password managers) was broken, too. That and uBO were the reasons I used Firefox on Android.

<comment><USER14> Both still work on my end. I am using nightly though. BTW, uBlockOrigin is one of the whitelisted apps.

</comment></comment><comment><USER32> I know this might sound blasphemous (useds uber alles seems to be today's accepted philosophy)… but one can have all the addons one wants, one just has to run `./mach build`…

Only grim for those who chose not to (for whatever reason short of missing hands or bashed in cranium), or cannot be bothered…

<comment><USER6> I doesn't say "grim" because you personally cannot circumvent the restrictions, it says so because of the impact this is going to have on the add-on ecosystem. Your trick isn't going to do you any good if nobody is developing/maintaining add-ons any more.</comment></comment>


Bitcoin Cash Hash War - <AUTHOR> https://cash.coin.dance/ <comment><USER2> How does SV have so much more hashing power but so few network nodes?

Also what portion of the BU/ABC hash power are malicious SV nodes? Or will we not find out until the hash war begins?</comment>


Amazon leaves sellers without remedy after 1p automated pricing glitch - <AUTHOR> http://www.theguardian.com/technology/2014/dec/15/amazon-sellers-discounted-glitch-pricing

<comment><USER2> The Guardian should be ashamed of itself, what utter twaddle.

Third party sellers used RepricerExpress to auto-price their goods. RepricerExpress screwed up and priced everything to 1p. Sellers lost TONS of money.

But reading this article you'd blame Amazon for this:

> Amazon has refused to come to the aid of thousands of small family-owned > businesses that have lost tens of thousands of pounds due to a technical > glitch that caused their products to be sold for a penny.

No mention of a third party, they clearly want the reader to think that it is an Amazon technical glitch.

> The sellers, many of whom are operating from their garage or spare bedroom, > have demanded that Amazon take some responsibility for the error caused by a > third-party software glitch. Some have already instructed lawyers.

Why? Just why? Amazon had no part in causing this. The sellers used the software, the software broke. Amazon doesn't own or make it.

> Amazon has accepted no liability for the loses suffered by its sellers, from > whom it takes a slice of each sale helping it to make annual profits of > $20bn.

Why would they? They didn't do anything that they could possibly be liable for!

Literally the term "RepricerExpress" doesn't appear until the 9th paragraph, halfway down the article. The article clearly tries to place blame at Amazon's feet (going so far as to suggest they're liable for this!).

Seriously this is the worst article I've ever read on The Guardian's website. It is intentionally misleading tabloid junk of the worst kind. The first article on this topic is far better:

[http://www.theguardian.com/money/2014/dec/14/amazon- glitch-p...](http://www.theguardian.com/money/2014/dec/14/amazon-glitch- prices-penny-repricerexpress)

The same author then wrote this second article, linked back to their first article, but tried to blame it all on Amazon in the second article (while giving correct attribution in the first to RepricerExpress).

It is just strange. This junk gives the Guardian a bad name.</comment>


The Value of Undefined Behavior - <AUTHOR> https://nullprogram.com/blog/2018/07/20/ <comment><USER3> Its undefined because it's not guaranteed to happen, that's the whole point, and that's what makes it undesirable. Rust has it right here: don't allow undefined behavior and make the programmer specify the behavior they want.

If they want wrapping overflow, fine. If they don't, great. Tell the compiler don't make it guess/assume/optimize/hope. What this article is arguing for IMO is not the concept of behavior that happens to sometimes work and sometimes not depending on the target machine (because thats crazy) but the functionality itself, which is valuable, and should be explicit and defined. The issue is the last-generation languages like C/C++ don't give you mechanisms to express what you want so you're left hoping the compiler figures out what you meant. That's not a world I want to live in anymore, we can do better.

UB is bad, period. Define what you want, make the compiler do it.

<comment><USER4> _Rust has it right here: don 't allow undefined behavior and make the programmer specify the behavior they want.

If they want wrapping overflow, fine. If they don't, great._

What if I know overflow can't happen (e.g. I have an integer counting from 1 to 10)? How do I say "it doesn't matter how you handle overflow; just do whatever is fastest"?

<comment><USER5> The parent spoke a bit too broadly. Here's the rules:

* overflow is a "program error", not UB

* compilers must either check for overflow and panic, or two's compliment wrap

* when debug_assertions are on, implementations are required to panic on overflow

This means release mode wraps today, but if it's cheap enough someday, we could make it panic.

If you want specific semantics on overflow, then you should use the various wrappers and/or methods that let you do them directly, rather than relying on any of the above. But you don't _have_ to specify; by default, the above is the semantics.

<comment> Paul-ish What if rust got "unchecked" (unsafe) versions of arithmetic operations that have C arithmetic semantics. Kind of the opposite of "checked_add".

<comment><USER5> It's possible! Nobody has ever proposed it...

</comment></comment></comment></comment></comment><comment><USER6> This is a fine opportunity to link to one of my favorite essays on the subject, Undefined Intimacy With the Machine: [http://thoughtmesh.net/publish/367.php](http://thoughtmesh.net/publish/367.php)

This argues that it is precisely C's undefined behavior which allowed for its dominance.

<comment><USER3> I have a hard time accepting the premise that a language is better because you have to hope that it does what you want instead of telling it, and for that reason it has become successful.

In fact, the ANSI C spec even states from your link that "Undefined behavior gives the implementer license not to catch certain program errors that are difficult to diagnose." That's just not an acceptable tradeoff anymore -- in fact I don't know it ever was. That's akin to shipping your org chart because you can't make your program do what everyone agrees it should do. You know, catch programming errors, in this case.

<comment><USER6> The paper argues that some behaviors being undefined let compilers target the widely varying architectures of the early microcomputer era, while still using a language that remains at least somewhat portable between them.

<comment><USER3> Yes, but your program isn't doing what you think you told it to, which is worse, because the compiler tells you that it will, know what I mean? A false guarantee of safety is kind of the worst.

<comment><USER7> > Yes, but your program isn't doing what you think you told it to,

Your program is still doing what you told it to if you weren't relying on any undefined behavior (Which, obviously, you shouldn't be). That's the point - <USER2> you write C that doesn't rely on any UB, then it can run on a large variety of architectures, work exactly the same on each one, and still get close to the maximum speed for each architecture because they can take the fastest possible option for any of the UB cases (And your program shouldn't care what they do in that situation).

<comment><USER8> The problem I generally have with C is that the scope of UB is really wide. Languages like Common Lisp have UB too, but it's generally easier to avoid in "normal" code.

<comment><USER9> In CL case the "is an error" wording generally covers all of C's "implementation-defined", "unspecified" and "undefined". And surprising amount of normal looking constructs are in the implementation-defined category.

When you add type declarations and (optimize (safety 0)) into the mix you get similar scope of UB as in C (another thing is that in reality nobody actually writes code like that)

<comment><USER8> I'm thinking of things like it being UB to modify a reader literal because the reader is allowed to do things like tail sharing.

<comment><USER9> I think that modifiing reader literal is an error mostly to allow implementations to store such pairs in read-only pages (eg. in .rodata section when you build standalone executables) and to allow simple implementation of CDR-coding for reader literals (dfsch has three distinct implementations of abstract <pair> class for exactly this reason and to be able to actually signal meaningful error condition when you violate this restriction).

<comment><USER8> But it's not an error: for some of these cases the standard doesn't specify the consequences and most implementations don't throw an error if you modify a reader literal, even if you end up modifying the interned list.

<comment><USER9> "Is an error" is wording used by the standard for things that are left undefined. For things that should signal some kind of error condition the standard uses wording "an error is signalled", the set of such cases is surprisingly small.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> To those annoyed about, say, signed integer overflow being undefined: do you even have a habit of ensuring that what's inside your loop will behave correctly around an overflow boundary? Is the real problem really only the loop increment for you?

<comment><USER11> The problem is tractability. If you send me your data, your source, and your OS and if I compile it with a slightly different compiler and I can't reproduce it gets incredibly frustrating to hunt down _why_ something isn't working.

<comment><USER10> Interesting, this is a less common complaint than what I usually hear. It kind of makes sense if you run into this a lot (I don't in C++, but maybe it happens more in C?), but at the same time I'm wondering why can't you just e.g. use -fwrapv if you want to rely on integer wrapping in your release executable? It also doesn't sound like it's related to using a different compiler, since using the same compiler with a flag like -fwrapv or with optimizations disabled should also prevent UB from being exploited.

<comment><USER11> Sorry, I miscommunicated. I was not speaking about integer wrapping, I was speaking about undefined behaviour in a general sense.

</comment></comment></comment></comment><comment><USER12> Excessive flexibility for optimizers, schedulers, etc. adds a high price to debugging, and it's not like we have perfect programs that can only be improved in these fancier ways.

Programs are not all written by experts. Performance may be left on the table in areas that have nothing to do with optimizers or schedulers (e.g. picking an absolutely terrible algorithm or not noticing unnecessary memory allocations).

 _If_ something must remain "unspecified", I at least want a debugging tool for that behavior. If something "may" happen, give me a switch to _make_ it happen. If something is data-dependent, show me the data that triggers a different outcome or give me a way to scramble data enough to increase the chance of triggering a change in behavior.

</comment><comment><USER13> "Value" is the wrong word, because it implies goodness. It's taken me a while to come around to this viewpoint but I think "undefined behaviour" is unambiguously bad in pretty much every context. I understand why it was originally included in language specs but in modern times, where even the meanest embedded processors are generally 32 bit 2's complement processors with an ALU, we can afford to define the behaviour of the language which we're using.

<comment><USER14> One example of undefined behavior is dereferencing a free'd pointer. How should that be defined?

<comment><USER13> In a perfect world it would either be impossible by design or result in a compile error. I'd settle for "reliably crash with an error message saying where in the code it happened".

<comment><USER15> You can get it in C. Just set the pointer to NULL after free, you will get your crash, problem solved.

<comment><USER16> How would that work if you have two pointers pointing to the same object?

<comment><USER15> If your design is such that you destroy thinks more pointers point to you have way bigger issues than UB or even language you use.

<comment><USER16> Are you saying that a program should have exactly one pointer to each allocated object?

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> The problem with the first example is that `int` and `unsigned` are not the correct types to be using for array indexing. As we saw, they were 32 bits wide on a 64 bit platform, which lead to an additional sign extension and (in the case of `unsigned`) truncation instruction. However, this can be avoided by using `ptrdiff_t` and `size_t`, which are defined to match the platform size and avoid the extension and truncation altogether. The fact that signed integer overflow being undefined allowed the compiler to elide the `int` truncation is somewhat irrelevant, since using the correct integer types leads to even faster code that doesn't rely on undefined behaviour at all.

</comment><comment><USER18> > What irritates a lot of people is that compilers will still apply the strict > aliasing rule even when it's trivial for the compiler to prove that aliasing > is occurring

I think better diagnostics for this would be a win for everyone.

</comment><comment><USER19> Defined behavior is a mere shadow of undefined behavior. All form comes from the constraining definition. One who limits his explorations to the defined has crawled into a hole and pulled in the hole after him.

Ya, I know, offtopic.

</comment><comment><USER20> * Most forms of undefined behavior don't have any meaningful use to compilers.

* With integer overflow it would be relatively easy to write a spec that allows "n+1>n" optimizations but not utterly _anything_ to happen. With strict aliasing it's probably not too hard either. You'd still see some program misbehavior in the strict aliasing case, but it would be a vastly reduced set of misbehavior. And allowing signed numbers to act more like abstract numbers would often _decrease_ misbehavior.

</comment><comment><USER21> If these are the best justifications we can come up with, it doesn't change my opinion that the current reliance on UB by compilers is a bad idea. Anyone got any better ones?

<comment><USER18> It makes your code many times faster in a lot of cases?

<comment><USER21> This article gives two examples where UB arguably helps you, and in each case the article itself mentions a cleaner and better way of doing it.

Magic behavior of "int" (but not "unsigned int") --> just use a type that's the correct size and better conveys your intention, like "size_t".

(And that one doesn't make your code "many times faster", in the example given it saves a single instruction.)

Type-based assumptions about aliasing (with a special case for char*) --> be explicit about your intention with the "restrict" keyword.

</comment></comment></comment><comment><USER22> This is a good history lesson on why UB was introduced, but times have changed and it is definitely not justifiable today.

Saving one instruction was probably worth it in the 70s, when security wasn't a thing, but it definitely isn't now.

<comment><USER14> Are you objecting to the UB in the specific named cases (aliasing and signed overflow) or UB in general?

<comment><USER22> In general.

</comment></comment></comment><comment><USER23> I really think that undefined behaviour should be switched to machine- dependent behaviour everywhere and we should just have tools that can suggest optimized variants of hot functions - to be rewritten in ways that take advantage of assuming undefined behaviour doesn't happen. Or lift the `extern "lang"{}' construct from C++ to C and have `extern "C-strict"' which turns on full strict undefined behaviour optimizations. Yes, I _know_ I can turn most of them off. We ship C++ software and always compile with singed-overflow enabled and strict-aliasing disabled (among others). Those are just too dangerous to be turned on for an entire codebase of a large C++ application where you have no idea what will be inlined where and what LTO will do. But if some UB allows for measurable performance gains, we should be able to turn it back on for restricted safe scopes.

And please, if the compiler can prove that the program invokes UB in "strict- UB" mode, that should be an error, not a cause for the code to be deleted. I'm talking about the case of this SPEC 2006 code [1]

It doesn't make sense to me to just apply potentially disastrous micro- optimizations that save a couple of percent of run-time on the whole program. This sounds like a classic case of optimizing before measuring.

1 [https://blog.regehr.org/archives/918](https://blog.regehr.org/archives/918)

<comment><USER24> > This sounds like a classic case of optimizing before measuring.

But you have done the measurements, right?</comment></comment>


DDoS attacks on Mt. Gox delay rollout of new virtual currency - <AUTHOR> http://arstechnica.com/security/2013/04/potent-ddos-attacks-on-mt-gox-delays-rollout-of-new-virtual-currency/?id=mrb

<comment><USER2> >Mt.Gox is the world's largest bitcoin exchange, handling about 63% of all bitcoin transactions as of April 2013.

A decentralized currency should not rely so heavily on a central exchange.

<comment><USER3> Well it doesn't exactly rely on a central exchange. Unless you're trying to day trade with Bitcoins you don't need to trust a central authority for very long with your Bitcoins. Due to the small size of Bitcoin a popular exchange is attractive but it's not like everyone can't switch to Bitfloor if MtGox closes today.

<comment><USER2> I should have worded that a bit better.

The majority of Bitcoin trade occurs at Mt.Gox, so you could say the market is pretty centralized.

Actually, Bitfloor had to cease all trading operations indefinitely. That aside, there are plenty of other reputable exchanges that need to gain more market share. It's ridiculous that a DDoS attack could be used for price manipulation purposes. That shouldn't be too much of a problem in a diversified market.

</comment></comment></comment><comment><USER4> FYI, the title was "77 Gbit/s Distributed Denial-of-Service on MtGox". I get confused when that happens.

</comment><comment><USER5> Some solidcoin folks have some (seemingly) irrational beef, but 77Gbit/s?

<comment><USER6> Wait, Solidcoin? That's still going?

<comment><USER5> Withholding my opinion, but it's interesting. The solidcoin community seems to be plagued by mistrust, conspiracy theories, alternate views about directions for the project, etc. [http://solidcoin.info/solidcoin-ready-for-bitcoin- collapse.p...](http://solidcoin.info/solidcoin-ready-for-bitcoin-collapse.php)

There are also a number of pastebin / IRC logs shedding more light into the dispute. Doesn't make a lot of sense, but it makes slightly more sense than the other theories I've seen proposed.

</comment></comment></comment><comment><USER7> Mmm... the first question that comes to mind for me is, "Who has a motive to do this?" I really doubt this is a bunch of #anon kids playing around, or anything like that. This strikes me as being a very specific, directed attack at Bitcoin itself (given that Mt. Gox is one of the most important exchanges).

I hate to sound all conspiracy theory'ish, but I can't help but wonder if a State actor is involved in this. While Bitcoin might not be (by itself) the techno-libertarian / cypherpunk / crypto-anarchist Holy Grail that some people make it out to be, I expect at least some governments to fear it on some level... if for no other reason because it's something new and they don't understand it.

Or maybe it's being done by backers of a competing crypto-currency? Hmmm...

<comment><USER8> Usually it's someone looking to drive down the price, buy low, then sell high when it rebounds

<comment><USER7> Good point. Well, whoever it is, I hope Mt. Gox get their anti-DDOS situation squared away well enough to mitigate this and future attacks.</comment></comment></comment>


Fedora 18 introduces online disk snapshots - <AUTHOR> http://virtualization.info/en/news/2012/08/fedora-18-introduces-online-disk-snapshots.html

<comment><USER2> hopefully this would get implemented in Cloud platforms like OpenStack.</comment>


Attacking Merkle Trees with a second preimage attack - <AUTHOR> https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/ <comment><USER2> The authors of Keccak / SHA-3 came up with Sakura[0], a hash tree construction that's provably as collision-resistant as the underlying hash function and very flexible.

If you're designing a new system using hash trees, you better use Sakura trees or have a good explanation for why not.

Edit: I also wrote some demo code[1] for this attack when arguing with one of the IPFS guys about why they really shouldn't use Bittorrent BEP 30-style Merkle Trees. In order to get security with Bittorrent-style trees, the [length, root] pair really needs to be your cryptographic identifier, and you need to make sure they're always properly handled as a pair. There are just too many caveats to usage and we have provably secure alternatives.

As a former LimeWire developer, it makes me sad that Gnutella's TigerTrees avoided this vulnerability long before bittorrent's BEP 30 was published, and yet Bittorrent got it wrong. It was a well-known vulnerability, and was covered as part of my interview at LimeWire.

[0][https://keccak.team/files/Sakura.pdf](https://keccak.team/files/Sakura.pdf) [1][https://github.com/kmag/bad_examples/tree/master/bad_merkle_...](https://github.com/kmag/bad_examples/tree/master/bad_merkle_tree)

<comment><USER3> RFC 7574 Merkle tree solves that rather strictly (I am the author of the scheme).

Max file size is 2^64 bits, so the hash tree is defined as a binary tree covering the entire 2^64 range, leaf layer made of 1KB pieces. A hash of an empty range is defined to be 0, at any level. That way, each hash is reliably fixed to its interval ("bin").

There are some features derived from that. For example, you can _prove_ file size by showing a logarithmic number of hashes. A file is identified by its root hash (covering the entire 2^64 range), no additional metadata needed. And so on.

These days, the 7574 scheme is used in the DAT protocol.

<comment><USER2> Having an RFC is better than nothing, and I don't see any obvious vulnerabilities in your scheme.

I've posted several places about being able to take the hash of the rightmost chunk and log(N) other hashes as a compact proof of file length for a hash tree root. (Including, I think, the posts I had arguing with the IPFS folks about using BEP 30 Merlke Trees.) That's handy, but there's nothing novel about RFC 7574 there.

However, 2^64 bits is a bit of an arbitrary limit. What's the justification there? SHA-512 and SHA-384 support up to 2^128-1 bits, and SHA-3 doesn't have such a limit.

More importantly, I don't recognize the names of the RFC authors from any cryptographic analysis. There's a big difference between a scheme that looks pretty good to a ton of random people who have looked at it and a scheme designed and published by world-famous cryptographers. Has your custom tree construct undergone formal review by qualified cryptographers? It looks pretty good to me, but if I had to bet by career on the security of a tree hash scheme, I'd prefer to go with the people who brought us Keccak/SHA-3 (and one of the people who brought us AES, despite its known weaknesses).

<comment><USER3> 1\. 7574 is not "novel" indeed. About 10 years old, if you count the original draft.

2\. 2^64 is quite a lot, for a single file. The variant I described deals with a single static file. Also, it is a part of a network protocol, so there are some requirements. Like, using standard integer arithmetics for packet-level processing.

3\. Feel free to show it to any people you like.

</comment></comment></comment></comment><comment><USER4> This is a well known edge case of Merkle trees; my undergrad security course covered this as an aside and it is prominent on the wikipedia page.[0]

For those not familiar with the specific implementation issue, this post should be a fun read.

I don't know what's more concerning, that pymerkletools advertises itself for use with Bitcoin or that none of the contributors read the wiki page :|

[0] [https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_at...](https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack)

<comment><USER5> It's a bit strange to consider this even an edge case, and weird that one would even create a diagram (such as the one on the wikipedia page) that doesn't have a solution (such as a leaf node marker prepended). Why isn't the prepended leaf node marker included in the concept of a Merkle tree? Is there ever a situation where you'd want a Merkle tree that allowed this?

<comment><USER2> The original use case for Merkle trees were to compactly represent sets of one-time-use public keys. In that context, an attacker trying to exploit this sort of collision would end up presenting an interior node as a public key leaf node, but the size of an interior node is too small to be a valid public key, so no party that performs sanity checks on the public keys would be fooled by the attacker. In that case, tagging nodes as leaves or internal nodes is arguably a tiny tiny bit wasteful. That's the only argument I can think of, and it's a poor one.

Edit: Okay, the other valid argument for not using prefixes to tag leaves and interior nodes is that you're using the provably secure Sakura construction, which using suffixes rather than prefixes. There are a few advantages to using suffixes, such as being able to have a single node containing both data and child nodes without having to know the length of the data portion before starting to hash the node. There's also better performance due to memory alignment when hashing memory-mapped files (if using block sizes that pack well into memory pages and cache lines) if you use suffixes. But, suffixes vs. prefixes is a tiny nit to pick.

<comment><USER5> Okay, I guess in mathematical terms a better way to express the whole thing would be in terms of two hash functions:

h_leaf(leaf) which takes a leaf.

h_branch(branch_left, branch_right) which takes the two branches.

The important point being that one should not be able to find a leaf such that h_leaf(leaf) = h_branch(branch_left, branch_right) for any branch_left, branch_right.

Prefixes versus suffixes are just implementation details of the hash functions (i.e. h_leaf(x) = "\00" \+ sha256(x), h_branch(x,y) = "\01" \+ sha256(x + y) would also work).

</comment></comment></comment></comment><comment><USER6> This was interesting, but when you think about it, this isn't really a flaw as much as something inherent to the way it was designed.

Imagine you had some combinations of functions f, g, and h such that f(g(h(x))) = y. Obviously you could calculate that as h(x) -> g(h(x)) -> f(g(h(x)) = y, but then of course knowing h(x), or g(h(x)) would enable you to find y as well. So of course, due to the recursive nature of it, picking any set of inputs that were the outputs of a previous call would give you the same output.

That argument doesn't exactly fit multiple inputs, but the idea is the same.

<comment><USER7> You say that like flaws and inherent features are different. I say those are the worst kind of flaw.

I guess the point is, this property (value-neutral) of that design makes it unsuitable for real-world purposes. Since the implementations in question are meant for real world use, that makes them flawed, at least. :)

<comment><USER8> For fixed-depth trees merkle trees are fine though. I have used them for just such a purpose.

</comment></comment></comment><comment><USER9> [https://crypto.stackexchange.com/questions/2106/what-is- the-...](https://crypto.stackexchange.com/questions/2106/what-is-the-purpose- of-using-different-hash-functions-for-the-leaves-and-internals-of-a-hash-tree)

</comment><comment><USER10> I find this article and discussion unsettling. A large number of people made non-typesafe merkle trees (including bittorrent, apparently), and then were surprised that passing it incorrect types cause it to produce incorrect output.

I don't see how this is a vulnerability in the merkle tree algorithm. It just seems like yet another case of "python libraries contain bugs that are common in idiomatic python".

I guess since so many people have independently implemented the same mistake, the writeup is useful.

</comment><comment><USER11> I think I might be missing the point...is the attack just to pretend an intermediate hash was a leaf?

If you're providing a merkle branch to prove that a document you've hashed is in the set, then I don't see how this helps you at all.

</comment><comment><USER12> Another solution to this attack can be:

hashing root with tree depth as last step.

<comment><USER5> This doesn't work unless you can guarantee that the size of hashed sets is going to be a exact power of two, because otherwise subtree depths can differ.

<comment><USER12> Oh I meant the longest subtree, afaik depth of merkel tree is the longest one no?

Edit: Also I think element count can be also alternative for depth

<comment><USER5> > Oh I meant the longest subtree, afaik depth of merkel tree is the longest > one no?

I get what you meant, but it still doesn't prevent the second preimage attack, unless you're forcing all subtrees to be the same depth. Think about the algorithm for testing set membership. How would they use the tree depth to distinguish between hash(hash(leafA) + hash(leafB)) and hash(leafC) where leafC = hash(leafA) + hash(leafB) but leafC is NOT a member of the set? Keep in mind that leafA and leafB could be leaves of the longest subtree, but other valid leaves could be on valid subtrees that are one node shorter.

> Edit: Also I think element count can be also alternative for depth

Element count doesn't solve the second preimage attack problem either.

<comment><USER12> Oh I maybe wrong on this but I was assuming something like this

           ABCDEEEE
          /        \
         ABCD      EEEE
        /    \      /
       AB    CD    EE
      /  \  /  \  /
      A  B  C  D  E

From: [https://bitcoin.org/en/developer-guide#transaction- data](https://bitcoin.org/en/developer-guide#transaction-data)

<comment><USER5> Okay, if I'm understanding correctly, that diagram is a little unclear. Like I said earlier, using the tree depth works if the number of items in your set is a power of two, because then all branches of the tree are the same depth. In this case, Bitcoin is _forcing_ all branches to be the same depth by duplicating the final element to fill in the rest of the Merkle tree up to a power of 2. In the example, the power of 2 is 8, and the theoretical Merkle tree looks like this:

                    ABCDEEEE
                   /        \
               ABCD          EEEE
              /    \        /    \
            AB      CD     EE     EE
           /  \    /  \   /  \   /  \
          A   B   C    D E    E E    E

The diagram you linked doesn't show the full right side of the Merkle tree, because of a clever computational trick that they use to optimize storage and membership. Basically, if you compute and store hash(E) for the leftmost E, you don't have to compute or store hash(E) again to compute and store hash(hash(E) + hash(E)) for the leftmost EE. The diagram is showing _the computations_ , not the full Merkle tree.

Incidentally, a side effect of this is that you can't have duplicate transactions, because you wouldn't be able to tell between a E and F such that E=F, and E simply being duplicated to pad out to a power of 8. This works for Bitcoin because duplicate transactions aren't desirable, but it might not work for other applications.

<comment><USER12> Yeah I totally agree with you, my comment was, I learned first about merkle tree from bitcoin, so I was always assuming it is working like this in general. But seems they were filling leaves to power of 2

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> My preferred fix is including the total size of data in the root hash, since it's often convenient to know the total file size before starting a download.

</comment><comment><USER14> I think the Wikipedia reference doesn't do it justice - the article alone is already ~1500 words.

 _Sorry, I couldn 't help myself_</comment>


F.B.I., Challenging Use of Seal, Gets Back a Primer on the Law - <AUTHOR> http://www.nytimes.com/2010/08/03/us/03fbi.html

<comment><USER2> Wikipedia's general counsel, Michael Godwin, is pretty good at writing these rather biting replies to legal threats while nonetheless still hitting the actual legal points. Fun fact: yes, he's _that_ Godwin.

<comment><USER3> _Godwin_ is a _lawyer_?!? Good Lord, is there _nothing_ the world can't do to surprise me?

<comment><USER4> I'm not sure why you are surprised. Huge parts of the study of Law is the study of oratory, and that's to what Godwin's Lax refers. Given that the internet must be amongst the most interesting places for a lawyer to be involved, I'm actually surprised that more lawyers aren't more heavily involved in the subculture.

<comment><USER3> No, no, it's just the incredibly delightful fact that Godwin's Law was drafted by a real live _lawyer_.

<comment><USER5> It's not like there are penalties for breaking it. Actually, only benefits.

</comment></comment></comment></comment></comment><comment><USER6> Best passage of the letter from Wikimedia to the FBI:

«In your letter, you assert that an image of an FBI seal included in a Wikipedia article is "problematic" because "it facilitates both deliberate and unwitting violations" of 18 U.S.C. 701. I hope you will agree that the adjective "problematic," even if it were truly applicable here, is not semantically identical to "unlawful."»

Exactly. Just because the FBI doesn't like it doesn't make it illegal.

</comment><comment><USER7> It is truly worth reading both letters (linked from the article, but: [http://graphics8.nytimes.com/packages/pdf/us/20100803-wiki-L...](http://graphics8.nytimes.com/packages/pdf/us/20100803-wiki- LetterFromLarson.pdf) and [http://graphics8.nytimes.com/packages/pdf/us/20100803-wiki-L...](http://graphics8.nytimes.com/packages/pdf/us/20100803-wiki- LetterToLarson.pdf) )---it shows how easily a scary-sounding lawyer letter can be written with... less than strong support from the law it quotes. IANAL and can't say for sure that Wikimedia's argument is sound, but I sure salute them for their, ah, "politely feisty response".

<comment><USER8> One thing that a lot of people don't appreciate about lawyers is that they will almost always try to push people beyond what the law is capable of compelling a person to do.

A typical letter from a lawyer will mix in numerous requests (which have no legal basis and are merely things which would be nice for the client) amongst legitimate legal complaints. It is not any lawyer's job (except one you have hired) to precisely define which behaviors of yours they think violate the law. Thus, lawyers use the law as a lever to facilitate much greater benefit to their clients (to the detriment of whomever their client has targetted). This is a major factor why lawyers get paid so much.

<comment><USER9> People need to learn to refer the people that write these letters to Arkell v Pressdram

<http://www.nasw.org/users/nbauman/arkell.htm>

(and I say this, as a trainee lawyer)

</comment></comment></comment><comment><USER10> All lawyer talking aside, the logic of the FBI actions is astounding:

• The FBI needs to unambiguously identify itself to citizens.

• It will do this by having a special image that only it is allowed to possess, to be shown to said citizens.

• Citizens will recognize this as the "image that can only be possessed by the FBI" and authenticate the bearer as FBI.

• _Citizens may not possess or view any version of said image sufficiently detailed to be identified as the actual image._

And how exactly am I supposed to memorize this image so that I may rapidly authenticate the bearer against all possible simulations if I can't see it?

<comment><USER11> There is the same situation with the $100 bill. We all have to be able to identify a legit one but I would guess the US treasury would similarly have a problem with Wikipedia posting a "camera ready" image if a $100 bill.

The $100 bill image on Wikipedia is 659px X 289px and is marked "specimen." The FBI logo is 2000x2000

<comment><USER10> All Americans are allowed to possess $100 bills in their full detail. There are all kinds of restrictions on what we can do with them, but we can possess them and look at them any time we like.

Resolution isn't much of an issue either. Absent watermarks, there are lots of nice upsampling algorithms.

<comment><USER12> Your last is one reason for the microprint on the bills. You can't upsample "into" microprint, except on CSI/NCIS type TV shows...

</comment></comment></comment></comment><comment><USER13> Nice. +1 for the Wikimedia foundation. If people don't stand up for their rights, soon there won't be any rights to stand up for.

</comment><comment><USER14> Writing Scary sounding legalese filled letters is typically all it takes for a big government agency to get the other party to back down. The approach is simple: loudly proclaim "We have the law on OUR side - so do not mess with us" and then make all kinds of unreasonable demands while the other guy is "quaking in his boots". Unfortunately for the FBI, Wikipedia has had its share of legal tangles in the past so they clearly have competent (and unflappable) legal counsel. The standard chest-thumping scare tactics are unlikely to work here.

</comment><comment><USER15> The FBI seal, along with all other government seals, are public domain. We paid for them with our taxes. Yes, there are laws saying that you can't use the FBI seal to misrepresent yourself as an FBI agent, or acting on authority of the FBI, but you have a right to display the seal in other ways. Same as any other government seal. Wikipedia is using the seal in an educational manner. Fully protected and legal use of that seal.

</comment><comment><USER11> I agree the FBI went about this in the wrong way by threatening Wikipedia.

But would it be so awful for Wikimedia not to post a 2000px X 2000px high quality rendering of the FBI seal?

[http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US-...](http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US- FBI-ShadedSeal.svg/2000px-US-FBI-ShadedSeal.svg.png)

There are limits to free speech -- no yelling fire in a crowded theater and all that. I am just asking, is a huge, beautiful rendering really necessary and responsible? Maybe if the FBI had asked that question instead of threatening they would have gotten a different answer.

<comment><USER16> This poster has a point, why do you downvote instead of answering or disagreeing?

I'm rooting for the underdog (especially when it's a public service like Wikipedia vs the big bad US Government agency), but he's asking for Wikipedia's criteria for selecting the image size for display.

Apparently there are valid reasons, which the FBI will not like:

[http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_crit...](http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_criteria)

"(...) of sufficiently high resolution to allow quality print reproduction. Still images should be a minimum of 1000 pixels in width or height; larger sizes are generally preferred. The size of animated images is judged less strictly, though larger is still preferred."

<comment><USER17> The seal has been uploaded to Wikipedia as an SVG. SVG is a vector image format, which allows for arbitrary resizing without any loss in quality, while the PNG (raster) version is automatically generated on Wikipedia's servers at whatever size the user wants.

N.B.: I did not downvote.

<comment><USER18> Yup it is automatically generated Here is the image 300px wide [http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US-...](http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US- FBI-ShadedSeal.svg/300px-US-FBI-ShadedSeal.svg.png)

and 500px [http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US-...](http://upload.wikimedia.org/wikipedia/commons/thumb/7/70/US- FBI-ShadedSeal.svg/500px-US-FBI-ShadedSeal.svg.png)

</comment></comment></comment></comment><comment><USER19> Baader-Meinhof alert: just yesterday I was googling around about fair use with regard to logos and insignias when I came upon this: <http://en.wikipedia.org/wiki/Wikipedia:Logos>

Considering how impressively thorough their policies and guidelines are the FBI's action comes as something of a surprise.</comment>


Ask HN: Should I ask for 1% pre or post-money? - <AUTHOR>

I've been offered 1% as a reward for the work I have done, we agreed that this shares should be vested, the condition is that I will only get the 1% if or when the business closes the VC round. Should I ask for 1% pre or post-money? If I understand correctly, I should ask for 1% post-money as the business will be worth more post-money. Apologies for such a rudimentary ask, I just don't want to screw up the basics. <comment><USER2> Yes, Post Money. The Company is worth more, because the valuation also includes the actual money put in by the investor. E.g.

Pre Money Valuation : $10m Investment : $5m Post Money Valuation : 10 + 5 = $15m

1% of $10m < 1% of $15m

</comment><comment><USER3> If you can spare the time, read 'Venture Deals' by Brad Feld and also [http://blog.alexmaccaw.com/an-engineers-guide-to-stock- optio...](http://blog.alexmaccaw.com/an-engineers-guide-to-stock-options)

Also, it's not clear from your post what you mean by 'shares should be vested'. Do you mean one of the following?

\- The shares will be granted immediately, and fully vest only if/when the business closes the VC round

\- The shares will be granted and fully vest at the same time, only if/when the business closes the VC round?

\- The shares will be granted if/when the business closes the VC round, but will vest over some period of time after that

You say that the 1% is being offered as a reward for work you have done. If the shares are for _past_ work, then there should be no need for them to vest over a period of years. You've already earned them. If they vest in a normal fashion (4 year, 25% per year, 1 year cliff) then you're being incentivised for _future_ work, and not rewarded for previous work.

</comment><comment><AUTHOR> Thank you, this is very helpful, thank you for the reading suggestion.

\- The shares will be granted and fully vest at the same time, only if/when the business closes the VC round.

\- Shares are for _past_ work. Yes, no need for them to vest over a period of time. That's what I was trying to convey by 'vested'. What's the best way to express the same and not leave room for doubt?

I simply do not have the option of getting shares now. The condition is clear, if/when the VC round closes. This is what I'm getting in writing: 1% post- money vested at the time of issue. Since I can't get shares now, is there anything I can do to be protected against the scenario you described?

</comment><comment><USER4> Vesting makes no sense in your case, since the work is already done.

I would recommend you get shares now, in writing, properly done. Not at some future time. While on paper, getting 1% after the VC round sounds better, because you won't be diluted, in practice, what will happen is that the VC will tell the founders: "as a condition for my investment, you need to clean your cap table and renege on your promise to that person".

Whereas if you already got your shares now, there isn't much the VC can do (except natural dilution).

Summary: get on the cap table now. It's now or never.

</comment><comment><USER5> More important than pre or post evaluation is in writing. Also more important is to have the shares If there is a liquidity event without VC ever being taken.

By the way, if it's pre-money, there's no reason not to have the shares today. If it's post money and they're coming from the option pool there's little reason to settle for just 1%.

</comment><comment><USER6> Yes, especially if you are discussing it in the context of a VC round. After all you are getting your shares after...</comment>