omgitstom

I'm unsure why the distinction matters that was brought up in the post. It really comes down to what do you need to support, and how much weight you can swing.

Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.

I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.

(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)

My dad passed away with dementia in 2019, spent a lot of time in nursing homes and also making decisions about the care of my father. I actually got to see this first hand with his caregivers in his facility. The requests to put him on different drugs required me to do a lot of research, validation and getting out of pocket advice from a medical professional that wasn't associated with the care facilities.

As someone that has gone through this, there is a fine line to walk between doctors operating under their Hippocratic oath, caregivers, and patient wishes. My dad was prescribed meds that weren't helping his quality of life and had really bad side effects mentally and physically through the the mid-stages of dementia.

Being in the authentication/authorization space for a while, this couldn't be truer. If OAuth 2.0 was a compelling differentiator from your API standpoint, they are doing it wrong.

I love how Ajit keeps saying 'it does not happen' where traffic is limited or blocked. It was limited, we saw this by Comcast with Netflix back in 2014.

This is what we are getting ready to get back into. I do not want to have an internet where the ISP can hold me (the consumer) hostage to other companies to increase the ISPs bottom line. It isn't a good experience for the consumer, it isn't a good experience for providers of media and apps.

TL;DR

Twitter gave the police information about the phone number which registered the account that sent the seizure-triggering gif

AT&T gave the police information that is was a Tracfone prepaid account with an associated toll record that was an iphone

Apple gave them access to his cloud account which had all the incriminating details needed including email / picture of him with his drivers license and data about the victim

Bad is relative, it is bad compared to other more secure methods. But if you can't guarantee that your users have a smartphone, SMS is still a needed option.

They support 2FA through SMS / TOTP / U2F. Yes, if most of their customers use GA / etc it is free, but that isn't their only option...

If they implemented a provider, they will also charge for TOTP authentications.

I'm sure Dropbox is going to get a lot of flak for this. 2FA based on the provider that they use may not have been cheap. Authy is $0.09 an auth, if you integrate with Twilio, you get SMS charges that vary on price based on country / provider.

The easiest/cheapest solution is to roll your own TOTP and build an app. This is useful for web, but may be pointless on mobile (if the mobile device is unlocked, then you have access to the TOTP app or SMS).

Business people probably looked at the cost per user and couldn't offer it at a lower rate.

Here you go: https://cl.ly/3q3d293k2N3X

Head of Product @ Stormpath

It doesn't really matter where you start, as long as you can relate to the product and its customers. I've seen great PM from every beginning. My beginning was a normal comp sci background -> dev -> customer success manager (any support role is a great segway into product management role) -> PM. Having managed many PMs, it boils down to this:

Can you be an advocate for your customer for your product, regardless of intercompany demands?

Can you communicate your vision for what needs to be built effectively across the whole company?

Those are the two main skills that I try to distil for any PM that I hire. There is a 3rd which I call the auxiliary skill (these can be taught easily, hence auxiliary).

How do you validate your assumptions, remove cognitive biases to come to the best decision about the priority on what should be built when?

And a fourth, which comes down to background and personality:

Can you be a swiss army knife and help wherever the team needs you?

The product I currently manage is a developer tool, so taking a look at an example based on the 4 points:

1. Can you relate to developer pain points, market problems with identity, create great developer experience and understand where there are holes in the current product?

2. How can you use the tools at your disposal to communicate what we need to build to the engineering team, marketing, and executives. Technical and non-technical folks alike, even for a technical product that is sold to devs.

3. How can you manage feedback / signals from sales, developer evangelism, customer asks, and visionaries to create a roadmap

4. Demonstrate how you have needed to step out of your comfort zone to get the job done.

When interviewing, having a developer background is a must (but it is only a must because my product is currently catering to the developer persona), but replace a developer product with a dental product that is sold to dentists. That hiring manager is going to want someone that more than likely understands dentists and their pain points that the software is currently solving for. They could come from, office manager, dentist moving to software (it happens), someone from the insurance industry... you see the point.

Hope this helps, I'm always happy to help and advise. Snag my twitter handle from the profile and shoot me a DM.

Auction information is here: https://github.com/theshadowbrokers/EQGRP-AUCTION

This question is a little vague. My assumption is you mean a REST API.

This is a must watch and encapsulates good design and theory: https://www.youtube.com/watch?v=hdSrT4yjS1g

Good API design, if you are trying to learn from zero, comes from learning from good examples.

These are some of my favorites APIs by design

+ Stripe

+ Twilio

+ Slack

+ Stormpath (fd: I work here)

There is a lot of work that goes around the API design to make it a great API (examples, documentation, live samples, etc)

"The U.S. Marshals Service (USMS) offers property for sale to the public which has been forfeited under laws enforced or administered by the United States Department of Justice, its investigative agencies (Drug Enforcement Administration, Federal Bureau of Investigation, and Bureau of Alcohol, Tobacco and Firearms), and certain other federal law enforcement agencies. "

My guess here is that bitcoin is considered property and not currency, and there are laws around this.

Edit: Looks like they are treating bitcoin as property -https://www.usmarshals.gov/foia/directives/asset_forfeiture....

"Sleeping animals are incredibly vulnerable to attacks, with no obvious benefit to make up for it — at best, they waste precious hours that could be used finding food or seducing a mate; at worst, they could get eaten."

It seems pretty obvious that sleep had an evolutionary advantage to conserve energy when the species couldn't be productive. For example, human sleep during the night because we can't forage / hunt / find a mate during the night because our vision requires light.

Acquisitions are complicated in tax law. There was a good write-up about this in Forbes about a year ago that your question reminded me of:

http://www.forbes.com/sites/anthonynitti/2015/10/05/tax-geek...

I honestly don't know the answer to your question, though.

It isn't about the vesting periods, it is about the exercise period. Vesting periods are fine in most cases.

The exercise period is usually 90 days, if you leave a company.

What happens a lot is there is no liquidation event for years meaning that an employee with shares needs to make a decision fast to convert or lose their shares (which they earned) and that cost $$$. I've seen time and time again, where people get locked in because they need to drop 4-6 figures to exercise their shares.

If the employee loses the stock when he's fired early, then the company has a huge incentive in firing him a day before he vests, and thus he should regard the vesting compensation as nonexistent.

I've seen this happen a few times in SV where employees are fired 1-2 weeks before their vesting period. Sad when it happens. Not saying that all times it is because of the cliff, but people talk and are aware of companies that have done this.

All of these points are sound. There are some benefits of using a JWT over a session identifier, though. And I think that most of these were covered in the comments of your first post.

We have an implementation of JWTs @ Stormpath for Token Authentication. We help a lot of customers with token authentication / user management and Stormpath hold a whitelist of all unexpired tokens.

In the Stormpath SDKs, there is the ability to locally validate the token for speed or validate against our API to make sure the token hasn't been revoked.

A common strategy for our customers is to always validate an access token locally, but force refresh against the Stormpath API. This is a good way to not incur state in your application (Stormpath will keep the state for you).

The Stormpath Integrations (like Express / Spring / Laravel / etc) use cookies to store the tokens because we have been advocating for cookies as the JWT storage mechanism for a while:

https://stormpath.com/blog/where-to-store-your-jwts-cookies-...

Always happy to get feedback. Again, this article was written back in 2014, and will be updated.

In regards to your advice about id_tokens and access_tokens. Usually, what I've seen in most attacks is that if a malicious user can get one, they can get both.

A lot of your points though are valid outside of using JWTs. Open redirects vulnerabilities should be plugged and sanitizing user input should be looked at regardless of what you are using in a web application.

Definitely not pedantic! Believe it or not, JOSE was still a draft when this blog post was released into the wild.

Thanks, Evan. these are all good points, I'm surprised to see this on HN since it is an old article I wrote.

In regards to the replay attacks, if you are using JWTs in a 3 party setup, and they are validating JWTs locally (not sending them back to a validation endpoint), the jti claim won't be enough.

Thanks again for clearing that up! Considering this blog post may still have a use, I'll update it soon.

Every company will want a PM that understands their vertical. This isn't as simple as researching, a PM should never interview without using the product and using as many of the competitors products as possible.

Every company wants a PM that is a jack-of-all-trades. This could be any degree of technicality, UX skills, marketing skills, developer skills, design skills, customer success skills, sales skills, and PM skills (prioritization, specs / user stories / strategy / go-to-market / scoping / shipping etc). If you aren't a jack-of-all-trades, pick up some hobbies / books / go to meetups to make yourself as well-rounded as possible.

Every company wants someone that is deep in one of the areas above.

Commonalities between companies are they want someone that is a foot deep across every skill set, and a mile deep on one skill set.

Figuring out where you fall on the scale of things and make sure you find a company that is looking for your exact strengths is the most important thing to pass a PM interview. Screen the company as they would screen you. Once there is a match, then Sam's advice kicks in if they are looking for a Technical Product Manager.

For aspiring PMs, I highly recommend taking a job in customer success as a gateway into product management. You learn a lot about working with customers, prioritization, and should be aligned with seasoned PM's at the company for advisement and mentorship possibilities.

What has happened with web storage since 2015-09-09 that makes their recommendations out of date?

As a developer, I feel like I have more control over mitigating CSRF then XSS.

But where I have more issues is that OWASP clearly advises not to use web storage for identities:

+ A single Cross Site Scripting can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage. + A single Cross Site Scripting can be used to load malicious data into these objects too, so don't consider objects in these to be trusted. + Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice. + Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

I think if you really wanted to think outside of box for this, quantum entangled particles is your best bet for instantaneous low energy communication

To add to this, the author brought up another interesting point, the organization you belong to should not own the identity. This will allow the identity to be associated with 0..* organization and the data associated with your identity can travel, be shared, etc. This can be supported with a good authentication / authorization data model without decentralizing the identity.

To bring this back around, the identity does not require consensus, the naming does, and the claims about the identity does.

Side effects of Sprycel: http://www.drugs.com/sfx/sprycel-side-effects.html

Metal filings can wreck havoc on your lungs / eyes - please use safety precautions if you are attempting this at home

Does anyone know how many foxes they started with for the experiment?

I spend some time with API Gateway this weekend. Since I work at a company that has a product that helps customers with authentication and authorization for APIs, I am always curious where everyone else is skating.

Your section about authentication resounds with me loud and clear, I couldn't hack it out in 6 hours. This will be a pain point for anyone using API Gateway for anything other than a toy API.

And that kept my interest for about 140 seconds. Pretty damn good character:fun ratio. Bravo!