The author of this article appears to be unaware that the major record companies have a significant stake in Spotify[1]. Of course they're not going to support any attempts to undercut the market.
It's not legal to spy on citizens. Assuming the NSA (and likely not the FBI) held illegally seized data, it still wouldn't be admissible as evidence in a trial.
This was countered, above, in the states own motion.
Basically, 1.) that's not how they did that, 2.) even if it was, it wasn't illegal, as they did not know at the time of the search that the server belonged to a citizen and 3.) Ulbricbht hasn't even admitted the server was his so how could we have violated his rights if the server didn't belong to him in the first place?
People keep wanting to insist the government did something illegal here, but as far as I can tell, there's no evidence that speaks to that.
It actually requires neither. As many lawyers have pointed out in various threads, the defense team could have claimed the server was Ulbricht's property before trial, and had the motion failed, denied so during trial - so long as he never testified.
I suppose it is slightly weird, but it kinda makes sense from a "lawyered!" perspective.
The institute and the open letter are about maximizing the societal benefits of AI by funding research that provides net positives to humanity. The goal isn't to prevent the development of potentially harmful technologies.
I believe they intend to fund positive research so that researchers do not resort to projects that do not provide net good, for example, in fields like weaponry.
Not that safely developing hyperintelligent AI isn't an interesting topic. But I don't think AI research is anywhere close to that stage, considering that programmers largely still have to hard-code any actions that an agent can perform.
" The goal isn't to prevent the development of potentially harmful technologies" - actually, the goal includes "avoiding potential pitfalls". One would assume that creating danger towards humanity would be a pitfall.
While I believe that allowing CSRF is terrible practice, as a user of Doorkeeper, I think the problem here is Digital Ocean's atypical usage of OAuth2. When you request an access token for a resource owner in OAuth2, you are supposed _actually authenticate_ the owner. According to the OAuth2 spec[1], username and password are REQUIRED fields. Allowing clients to generate tokens based off of cookies is reckless.
Useful CSRF exploits depend on the server to trust session data to authenticate client actions. OAuth2 is designed for allowing external (third-party) applications to communicate with you. Cross-site requests are an expectation in OAuth2. If you ignore the spec and skip proper authentication, you're in a bad spot anyway.
> According to the OAuth2 spec[1], username and password are REQUIRED
> fields. Allowing clients to generate tokens based off of cookies is
> reckless.
It's possible I'm not understanding you correctly, but the section of the spec
to which you linked is describing the "Resource Owner Password Credentials
Grant", just one _possible_ flow for requesting an access token. In that same
section the spec reads:
> The authorization server should take special care when enabling this
> grant type and only allow it when other flows are not viable.
Also worth reading is the section of the spec dedicated to security
considerations (https://tools.ietf.org/html/rfc6749#section-10). There is an
entire subsection regarding the password authentication flow you're
referencing. Choice excerpts:
> This grant type carries a higher risk than other grant types because it
> maintains the password anti-pattern this protocol seeks to avoid. The
> client could abuse the password, or the password could unintentionally be
> disclosed to an attacker (e.g., via log files or other records kept by
> the client).
> The authorization server and client SHOULD minimize use of this grant
> type and utilize other grant types whenever possible.
Usually those implementations redirect the user to a separate authentication system. OAuth2 only handles authorization and not authentication. Upon successful authentication, the user gets redirected back to the OAuth2 request which then generates the authorization code.
When the user is already logged in via a cookie set by the authentication system (i.e. an existing valid session), they don't get prompted for a password again; the authentication system will simply redirect to the OAuth2 request url. The typical OAuth2 implementations shouldn't be reading the authentication cookies directly.
The "password flow" in OAuth2 is really a special case for those who want to bypass the separate authentication system and use OAuth2 directly for both authentication and authorization.
I can say that recently LinkedIn has asked me to reauthenticate on multiple occasions in the same session. I've had the same for Google but I have not tried recently. I'm aware that Twitter and Facebook allow you to do so, but I propose that none of the above give scopes without authentication that allow you to perform actions that charge an account.
That said, I agree that some of the giants are fine with using cookies for auth in OAuth2. And while that indicates that this is a possible use case, OAuth2 is capable of being used in many ways and Digital Ocean's usage still doesn't make much sense.
I can see this breaching their ToS and would probably be shut down by them if brought to their attention. However, what law would you be breaking when you give a private company a fake name.
Regretably, in the US the "Computer Fraud and Abuse Act" (CFAA) makes it illegal to access a computer without "authorization". Courts have interpreted that to mean that accessing a site when you are in violation of their terms and conditions (for instance, with a fake name) is a violation of this law and thus a felony. Learn more: https://www.eff.org/ja/issues/cfaa
Of course. The _whole point_ of _any_ ethical or moral principle is that it directs you to do things that are right even at some possible cost to yourself.
If you believe that standing up for your strongly-held beliefs will get you fired, you should look for a new job _now_. Sure, that incurs the trouble and uncertainty of a job switch, and possibly a pay cut (though perhaps less of that than you think). But if it means that you don't have to be ashamed of what you do all day --- it's generally worth it.
If we're talking about software development, I bet you can piece together a computer from the trash (where do you think my home servers come from :)) that will be good enough to run a company. After that, your only issue is food and rent (which can be either a small or big issue depending on where you live).
It couldn't handle files with spaces, plus the link it gives initiates a download for the file instead allowing you to view it in the browser. Considering most of the time I want to quickly upload a file in this manner the file is a screenshot, this is basically useless for me.
