ROARosen

I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API.

Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.

> poor sleep quality, headaches, stomach issues and back pain

While it's true that volatile-pay work is extremely stressful, this seems like a cherry-picked study to be able to write a flashy headline to people rightly concerned over a hot-button issue. They could have just as easily just said that volatile pay causes anxiety and stress, which IMHO you don't need a study for, just like we don't need a study saying that eating less increases hunger symptoms.

Anxiety and stress itself is a well-known cause of all these above issues, and there are a multitude of other work-related stresses than just volatile pay.

Is there no concept of a preliminary injunction in the EU legal system?

>Every API endpoint is a promise, and it's also a constraint on future innovation.

I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.

I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.

Great idea! will keep in mind.

Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner.

For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.

> There is a risk that if handed back another country might try to claim it for themselves

I really don't get this. What exactly is the risk? If they don't need it why do they need to make sure no one else gets it?

Ha. Happens to be there is a script out there somewhere which allows you to extract the private key of any of your MFA codes from Authy through Chrome DevTools (it's an Electron app) so you can use it in whichever MFA solution you want.

I find it interesting they didn't block you. Also, would this be affected by the latest changes at Twitter?

Arafat was chairman of the PLO from the 1960's, before the Lebanese Civil War started. These were his policies.

External actors, hmmm... I believe you mixed that up with internal actors like Hezbolla and others, who have a tight grip on the countries political system.

Last time I checked the leader of Hezbolla, which is part of the government of Lebanon said: "There is no solution to the conflict in this region except with the disappearance of Israel."

Not the other way around.

While they might sound convincing that they might mean this for everyone's good (and it might be good for everyone, this is typical of Google in GCP and elsewhere trying to force more modern experiences because "they know better" than everyone unwilling to upgrade their platform.

You pay according to location for the same bottle of Coke? How is work pay different?

Why shouldn't payment for work be tied to local price ranges and cost of living?