How did you deal with text injection into react forms on facebook?
Whenever I interact with text in a form field on facebook via a browser extension, it is not picked up by react, and the original text is what is picked up on submission. I've banged my head into this problem repeatedly. Is there an easy fix or is this something much more subtle?
I mean on the encrypt side, not the decrypt side. When I try to put text into a react form, react doesn't pick it up - it still uses the original text in the input form. I will definitely look at that code though, thanks!
I won't pretend to be an expert, but very vaguely, if I know anything about react: you would have to modify the local state of the form (if it's possible at all by a 3rd party in fb frontend code) and react/flux will modify the dom for you. If you go more directly (on the DOM for example) you will get overwritten by the current state as soon as react re-renders
sorry I'm not @lettergram, so I cannot really help you with his code; I never tried to inject code into a facebook page, but I can imagine that especially after minification it's going to be a pain to do
I actually would very much appreciate that. I was just reading Nakamoto's whitepaper on Bitcoin [1] and I understand the hashing. However, the coinebase transaction is still a bit confusing to me. Specifically, to get at precisely this issue - what does the bitcoin itself consist of? It is just the summation of the history of transactions to and from an address? Or is there a numerical value or token that is actually issued during a coinbase transaction, and, if so, how is it generated? This is not apparent to me. I understand that during a coinbase transaction, there is a transaction registered that is issued to the miner and the 'from' address is null - but it is still not clear to me, other than the balance of that transaction, if there is an actual token associated with those coins.
The core idea is that there are a number of coins "floating out there in the open" which you can use in your transactions, as Inputs. These Inputs can be used in transactions as long as you publish data which can solve a riddle put forth by a Script. So, your balance is basically any those which you can easily use as Inputs. The most traditional way of tracking this is that you use a standardized script format called P2PKH (Pay 2 Public Key Hash), and software like a wallet scans the transactions for any scripts that have your public key mentioned in a P2PKH template.
So, once you want to send money to someone else's wallet, you answer the riddle of the script (in P2PKH's case, by signing something and proving you own the public key) allowing you to do whatever you want to that Input. A key thing is that if someone pays you 3BTC and someone else pays you 2BTC, then you have 5BTC in combined inputs. To pay someone else 4BTC, you use both those Inputs and make two new ones: 4BTC P2PKH to someone else's public key, and 1BTC back to your own "change address", which is just an Input that you can reuse again.
A wallet broadcasts transactions into the network, where they float around until a miner takes those transactions, puts N of them into a block, then, as part of that block, they can use an extra magical coinbase Input which gives them 12.5BTC out of thin air (originally 50BTC, halves every so often) which they can lock under any script they want.
> It is just the summation of the history of transactions to and from an address?
It is. Imagine the blockchain as a democratic ledger. As long as most people agree a certain transaction is valid it then is valid. This allows for tricks like creating bitcoins out of thin air as long as everyone agrees you "deserve" those bitcoins. For example if you confirm enough of other peoples transactions (which you can do because the ledger is public) most everyone will agree that a transaction from nowhere to an address of your choosing is valid.
The amount of bitcoins in your possession is just the amount of bitcoins ever transfered to addresses to which you own the private key, minus the transactions out of those adresses.
You shouldn't think of bitcoin as a virtual coin. That's a fairly bad metaphor. It's not some actual thing, It's more like the balance in a ledger.
Right, that was my instinct, it is just that the documentation I have seen, including the O'Reilley bitcoin manual, on the coinbase transaction, glosses over this point.
I'm a technology lawyer. I deal with a fairly high volume of open source licenses and I write a lot of software licenses. I'm also a former developer and still have hobby projects I write mostly in javascript - primarily in Node.
I've read the BSD+Patents licenses. What am I missing? It seems like it is designed to reduce the power of patent trolls and to reduce the power of people who use software written by facebook to sue facebook for patent infringement - which, IMHO - is pretty reasonable, especially given that I think it is an absurdity that software is ever granted patents in the first place (something being rectified, albeit slowly, in the post 'Alice' world).
So, what am I missing? Are there any other actual lawyers who can weigh in on this? Because I see a lot of FUD on here written by a lot of arm-chair lawyers and, when I go to read the licenses (which I do) I'm just not seeing it. I very much believe in evidence and I am always open to counter-arguments - so please, show me the problematic clauses or the problematic exercise of clauses by Facebook.
As of now, all I see is a license (probably written by Goodwin Proctor or Fenwick & West) with a restriction on initiating patent-based litigation - I can live with this. Again - I'm happy to stand corrected.
Disclaimer: I'm not your attorney, this is not legal advice, this is not an official legal opinion nor the opinion of my law firm.
Thanks for that link. It was a concise and good read.
I don't like the terminology used for the patent retaliation clauses. I see the "weak patent retaliation clause" as fair (within the scope of patent retaliation) and the "strong patent retaliation clause" as harmful.
If I had a say in the matter, I'd like to call a spade a spade and help people understand what these really mean. The terms "weak" and "strong" in this context appear meaningless to me. Without explaining what the clauses mean, the terms themselves don't provide any indication of the (comparative) utility of these.
So the concern is that if you are a company with a large patent portfolio, and you sue facebook for patent infringement unrelated to react, facebook will yank your react license?
I'm also a technology lawyer, i've written several of the patent grants used very widely, as well as having been responsible for open source licensing compliance at Google for a very long time .
If i thought this license would actually help i would support it in an instant. But so far
1. i don't believe it would. It's a very old idea, discussed to death, with a lot of downside, and a little upside.
2. they've ruined a lot of the possibility of getting people on board by doing it in a way that's fairly tone deaf.
As for the license itself:
You also have the same concern if you aren't large.
It's also not just going to yank your react license, it will yank your license to everything under this license.
This license will not have the effect of stopping patent litigation. Patent trolls don't use React, and most of the danger is still trolls.
If you really wanted to play that game, you'd be better off saying "if you sue us, you lose the right to use facebook the service". That might have some effect (but probably not a lot).
Instead, this license will have the main effect of further enabling the large to leverage the small. Hey, seems like you got technology i like, and hey, looks like the app you depend on for your livelihood uses react. it'd be a shame if you had to sue us for taking your stuff and lose your react license.
Do i think facebook will do that? Honestly, no. I doubt it. They may by accident. Do i think, if widely adopted, it would have that effect: 100% yes.
As for the origins, these kinds of broad termination clauses have been around forever. They aren't anything new. As i've said before, they were considered and explicitly rejected from most current licenses with patent grants.
Rather than come to a community of license authors, etc, and say "hey, we want to re-explore this, because we're seeing a problem", they did it this way.
That's ... unlikely to be a successful mechanism (and in fact, i know a large number of corporate counsel who have banned it).
You make a lot of good points, but I want to focus on just one.
> This license will not have the effect of stopping patent litigation. Patent trolls don't use React, and most of the danger is still trolls.
I agree. However - implicit in your position (and my apologies if I am reading you wrong) is that there are small players - or any players - who have valid software patents that should be exercised against anyone - much less Facebook. As a general proposition, I'm hesitant to support that.
Let's put it another way - but first get some caveats out of the way: there may be things problematic with this license (your points are highly illustrative - especially about the systematic, higher-order effects). I also think that, as someone in private practice, I'm empathetic to Facebook's attorneys' goals here, and they are likely saving Facebook a whole host of headaches. I am also very well aware of the counterbalancing arguments regarding the duty of good stewardship of the open source community, and decisions like this by gigantic players such as Facebook have lasting effects for the entire community. /caveats
However - defense of the right to pursue infringement litigation over software patents against anyone is simply not a hill I am willing to die on. I am struck, as a result, by confusion at the willingness of open source lawyers to criticize facebook for license limitations aimed at limiting the rights of licensees to initiate patent suits - even if it is a self-serving limitation. My instinct is that, in general, push-back against limitation (even imperfect ones) of the exercise of software patent rights, within the open source community, should be a fairly low priority. I'm happy to stand corrected - it happens often enough.
Let me make a crude analogy - if you believe in certain forms of gun control, this would be the equivalent of a debate about what type of assault weapons may be owned by the public. If you are of the view that no assault weapons (and I am using the term very, very broadly - I'm not interested in the highly technical debates of what constitutes an assault weapon for these purposes) should be owned by the general public, then law banning the ownership of a particular type of assault weapon against by a particular class of owner is not that big of a deal - even if it is crudely implemented. If anything, it may be a step in the right direction. Accordingly, the criticisms of the BSD+Patent license by the open source community strikes me as analogous to criticism of a partial assault weapons ban by gun control advocates - it is a bit of a head-scratcher.
Back to this license, in more concrete terms - I am skeptical of the claim that there exists an entire class of small companies have that meaningful software patent portfolios that can be exercised against facebook, much less anyone, which companies will be disenfranchised of their rights by this license:
* First, software patents are severely diminished in the post-Alice world, as a category, and very likely to be invalidated in an enforcement action, especially against a company as wealthy and sophisticated as Facebook. Patent litigation with Facebook is going to be as scorched-earth as it can get - the arrow of the BSD+Patents license is but one in a quiver that is full of millions in cash and tens of thousands of associate hours.
* Second, if you have the wherewithal to enforce a patent, you have millions of dollars in attorneys fees at your disposal - meaning you are not very small. Patent infringement litigation is called the sport of kings for a reason - it is monstrously expensive (I seem to recall statistics stating that a 'simple' patent claim is on the order of $1.5-3M to litigate to conclusion, per party).
* Third, if you have non-software patents (e.g., medical devices, drugs, chemical compositions, manufacture processes, semi-conductors, etc.) - it strikes me that there is a low (maybe not zero, but low) chance that facebook's BSD+Patents license constitutes a substantial portion of your 'critical' software stack.
* And, finally, if after all this, you are a small startup without a lot of money and you are trying to enforce software patents against Facebook (of all possible litigants, I can think of no larger juggernaut), and react (or any other BSD+Patents licensed software) is a part of your critical stack - there are so many other existential questions about the company's strategy that the particular terms of this license are rather low on the list.
As I said, I am very happy to hear any feedback, and thanks for your thoughtful responses.
Edit / update:
A few notes, in no particular order:
Tl;dr - two main cases here: 1. one is trying to enforce software patents against facebook - I am not going to spend a lot of energy defending the exercise of software patents, generally; 2. one is trying to enforce non-software patents against facebook - I believe there is a low chance that Facebook's BSD+Patents software constitutes a meaningful part of your stack in this instance.
* You are likely viewing this issue from the point of view of someone who chooses what sorts of licenses Google should adopt. I very much appreciate your insight and criticisms from that perspective. However, I am viewing it as counsel to a lot of small companies that have to be nimble - accordingly the scenario in question, where this license is a limitation of a startup's ability to succeed, involves that startup having been misguided into thinking that it is a good idea to sue Facebook for patent infringement over a software patent while also relying on Facebook software as a part of their critical stack. That is... quite a scenario. It reminds me of this scene from Dark Knight:
Lucius Fox: [in his office] Let me get this straight. You think that your client, one of the wealthiest, most powerful men in the world, is secretly a vigilante who spends his nights beating criminals to a pulp with his bare hands; and your plan, is to blackmail this person?
"As a general proposition, I'm hesitant to support that."
I'm even fine with this (I hate software patents).
But it seems very wrong to essentially be able to take what you want from small companies because they are afraid to take you on.
Regardless of what mechanism you use to achieve it.
"and they are likely saving Facebook a whole host of headaches."
I am empathetic, but i also disbelieve this. I'm aware of every headache Google has ever had in these situations, and i can't imagine Facebook's are particularly different.
I can state affirmatively that this license would not have prevented even one of those headaches.
Thus it would have been infinitely more helpful if they had cited any examples.
As for your viewpoint on the scenario. FWIW: yes, i am certainly biased by what i've done. But I actually have dealt with a tremendous number of startups, from both sides of the fence (I also do due diligence on this side, and have helped plenty on the other side). The number who would have no effective recourse under this license, who would have had effective recourse before, is quite high.
Would that recourse only come into play when they are essentially fcked anyway? Yeah, maybe. But it's worth something*.
Hi Danny, thanks for your insight about this topic. As someone who works with licensing at Google can I get an idea of what would happen in this scenario.
Let's say Facebook has a Patent on something like `Components`, `Unidirectional data flow`, and `virtual DOM` which were core to React (of course, we don't know for sure). Now let's say a framework built at Google using the same ideas as `Components` and `Unidirectional data flow` under MIT. From what I can find about patents is that if you have a Patent on the eraser then that prevents anyone from building the pencil or at least the eraser can sue for patent infringement. Does this mean the framework that was built at Google under MIT can still be affected by Facebook? If that were the case can we assume Facebook wouldn't sue Google for the same reason as start-up wouldn't want to sue Facebook for patent infringement? What if a startup were sued Facebook for patent infringement and Facebook counter-sues for patent infringement because of use of `Components` and `Unidirectional data flow` in the MIT Google framework do you think Google would step in to help since the startup wouldn't have enough money to take on the counter-sue?
The idea here is that no one knows for sure what Facebook has for Patents on React yet the core concepts that were introduced to the community is wide spread.
Disclaimer:
Of course, this is just hypothetical and you're not my lawyer and this is not an official legal opinion nor the opinion of Google.
> The number who would have no effective recourse under this license, who would have had effective recourse before, is quite high.
I think that's the rub. If that is the case, then this is certainly very problematic.
In any event, this is certainly a class of licenses that needs to be watched carefully on an ongoing basis and added to the (already substantial) checklist of licenses that need to be carefully considered before being added to any project.
I appreciate your comments and candor on all of this, btw. Thanks again.
@libertymcateer - the scope is still broader than what you're focusing on: first of all, it's not just software patents (I know you mention this, but it's worth emphasising) and secondly it could be a company you have a share in sueing a company Facebook has a share in, about ANY patent infringement. That act alone is enough to revoke your company's licence to use React.
I have been saying this for quite sometime on this forum - contracts have to deal with ambiguous circumstances and expressly contemplate being resolved in courts. Ambiguity of contracts is a feature, not a bug, as it is in the interest of both parties to be able to argue about certain unanticipated events when they occur.
Quoting my own comments from a while back:
> The vast majority of contracts do not have syntactically testable conditions. They just don't. Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about. Unless you can create a condition that is testable by code, you cannot have a contract that self-enforces with the block chain. The conditions set forth in contracts are extremely complex and reasonable people can differ. I cannot imagine how you would have a contract be triggered on the insolvency of a privately held corporation - good luck defining insolvency and good luck getting access to the underlying books. Copyright infringement is also a preposterous idea - the amount of semantic judgment that must be made to determine if a work is infringing is enormous. Only the very simplest of conditions - comparing numbers, checking the time, can be reliably automated, and if you are getting a lawyer to write your contracts, odds are there is substantially more complexity in the agreements than this, which is why you hired the lawyer in the first place. In addition, a fair portion of contracts that can actually be set up to work this already are - and the blockchain is not necessary. They are things like credit cards and they work pretty good without the blockchain.
Don't worry, if the developers don't like the ways contract turned out for them, they can always for the chain and revert it. Which is sort of like a court, right?
That's why a strongly advocate for using Ricardian contracts over smart contracts in most cases. R contracts can contain standard legal prose while delegating specific clauses or portions to embedded smart contracts (embedded by hash or bytecode).
You can go from LLC Name (Foo, LLC) to Registered Agent Name in 30 seconds. You cannot do the same with Company Name to Bank Account (or from Bank Account to Owner Name).
I also use a registered agent for all my LLCs, but you don't have to. You can totally put your own address down when doing paperwork, and then your home address is open to the world.
"Ellcrys" is a word that is likely subject to trademark and owned by Del Rey.
Its unauthorized use, is, at best, 'iffy.'
This aside, I've already written on HN about how I am deeply skeptical of self-executing contracts. Contracts can fit roughly into two types of categories:
1. Those with easily measured standards - which have largely already been automated without having to invent new technologies (e.g., turning on autopay on your cellphone).
2. Those with hard to measure standards - such as a "material advertise condition" - which do not lend themselves to automation without human intervention. In contracts of any sort of substantial complexity there will be myriad conditions that are intentionally vague - written this way because the circumstances are hard to predict, as catch-alls, and also to allow for some leeway to maneuver in the future. Or, to be more cynical, to allow your lawyers to argue over the definition in the future. This vagueness is a feature, not a bug, and even if we could implement AI technology to make these decisions with high degrees of precision, business people still not want to implement them because it is ceding control to an unknown third party. In other words, if you are selling a business, you are simply not going to have it be done through a self executing contract. It is not going to happen - it is just too nuts.
Then again, I do enjoy being proven wrong. So only time will tell. I am sure that more and more contracts will become the self-executing type, but I am also fairly sure that self-executing contracts will only ever amount to a small percentage of the contracts that are used 'in business.'
> "Ellcrys" is a word that is likely subject to trademark and owned by Del Rey.
umm, I will be looking into this. Thanks for the heads up.
I understand that there is a lot of debate about what a smart contract is, its legal scope and functions. However, we are not only building to host legal contracts but contract applications that are user-facing or API-based, owned and maintainer by teams or communities. These are the kind of contracts I believe will be most useful and practical today
Let me be totally clear about something: you have built something interesting and you should run with it. You will hear a ton of criticism, including on this forum, telling you to pack it up and take it home. That is bullshit. It is easy to criticize and hard to build. I'm often wrong - and I've been in your shoes. It can be hugely discouraging to read a bunch of criticism on hackernews. Don't take it too personally.
Keep on pursuing. At some point, if you do have to call it quits, make sure it is a reasoned decision based on (1) having already made your best efforts and (2) market feedback. Don't base it on the stuff you read from internet strangers.
Right now, in America, your browsing history is basically for sale by your ISPs. That it may not be actively happening right now is coincidental - it is an impending certainty.
If you are okay with that, godspeed, but I think you would have to be deranged or clueless (or both) to be okay with the idea that mega-conglomerates can sell your personal browsing history to the highest bidder.
There are myriad other legitimate concerns, but this alone makes the whole debate something of a non-starter in my opinion.
In my experience as someone who has been in-house counsel and now outside counsel for a variety of tech startups and software development shops, and has watched this happen in the careers of a lot of people around me (usually while being the sole 'suit' in the room), the transition you are describing usually happens in the late twenties or early thirties.
It is basically the transition away from the last vestiges of a "school-like" mindset to a "career" mindset.
In the "school" mindset, your primary form of social rewards are from the people you spend your day with - when you are a kid, your friends are all at school, and even though you go to school to do schoolwork, it is still where you see your friends. In the "career" mindset, your primary social rewards are the people you spend your nights with - which are friends who you do not work with, and, importantly, your family.
In other words, as a young 20something, it is easy to still be in the mindset that the 'fun' time is when you go to the place you spend all day at and do so with a bunch of cool people. A lot of jobs, as a result, try to recreate that 'school' experience with a gym, scheduled fun activities, playtime, etc. Howev er, when you are in your late 20s, even if you don't necessarily have a family or are an introvert, the appeal of this lessens dramatically, as you naturally spend more effort trying to carve out time for your own interests - whether they be your family, your hobbies, or even just solitude and meditative peace. Accordingly, it is really just far less important that work have a bunch of perks that require that you actually be there, than for work be a professional environment that respects your time and is financially and intellectually rewarding enough to be "worth it."
damn that is exactly my situation! it happened a little earlier for me though; i'd say around 27-28. it accelerated after working for google that short bit I did
I just regularly run `yarn upgrade-interactive` in my projects.
I was thinking of making dependency-updates part of the CI-pipeline, using a 'allow_failure'-flag. However, if you decide not to upgrade a dep for some reason, this will cause each and every build to throw a warning.
https://www.npmjs.com/package/npm-check-updates is a small command line utility that will report which dependencies are out of date, and can also upgrade your package.json from the CLI while maintaining your existing semantic versioning policies and ranges across an upgrade (instead of just bumping for every minor update).
Mostly I just really like the compact output, and the short "ncu" command which I run every day to check what's available :)
Definitely something to the addage "if it ain't broke don't fix it". Some of our less critical modules are set to latest others are updated with care. Our modules are not under source control so are refreshed on deployment. We use Snyk to monitor for vulnerabilities, works pretty well.
This so much - shrinkwrap before it bites you when a CI kicks off a deploy that fails because it pulled latest minor dep release that broke everything (happened even in big lib like Angular 2 for us after stable 2.2 !) while your local box is running fine with a cached older version.
Yes. I've had an app break due to a dependency's dependency update. Was the night before a big product launch. Learned to rely on npm-shrinkwrap the hard way.
But in addition to that, how do you "update all and bump relevant package.json entries, dependencies _and_ devDependencies as appropriate" ?
`npm update --save` or `npm update --save-dev` say explicitly "save updates to `dependencies` resp. `devDependencies`", which causes duplication between dependencies and devDependencies. (Say you have a dep foo and a devDep bar and both are outdated: `npm update --save` will bork package.json with an additional incorrect dep bar, and `npm update --save-dev` will bork it with an additional incorrect devDep foo :-/ )
Am I missing something? I understand there are 3rd-party packages providing such functionality, but is there any reason to not cover this feature in npm?
Yeah that's the package I meant with "3rd-party packages providing such functionality", thanks for pointing it out :) ! Was wondering if there was a reason other than "because no one developed it" for such a feature not being in npm core.
Whenever I interact with text in a form field on facebook via a browser extension, it is not picked up by react, and the original text is what is picked up on submission. I've banged my head into this problem repeatedly. Is there an easy fix or is this something much more subtle?