So it's not a status but just a per ride assessment -- if you appear disabled when the driver comes to pick you up, he should ask not to receive surge pay for that particular ride?
Many of the bullet points are somewhat vague, but one is strangely specific:
> Prohibiting companies from charging passengers with disabilities higher prices during busy times.
First of all, what constitutes 'disability'?
How will passengers identify themselves as 'disabled' to the apps?
How would the companies store this highly private information? (think medical-info grade, not credit-card grade)
What will indemnify the companies from claims of discrimination, claims possible in light of the companies being aware of users' disabilities, information they never wanted to keep in the first place?
And finally, not to make it the main topic, but who would pay for this? That "surge pricing" you pay is, in turn, being paid to the drivers. The drivers are "chasing the surge'.
WebRTC is somewhat new and complex, and browser support varies greatly. I don't know what kind of unlimited resources behemoth you imagine Slack to be, but I can definitely see how doing consistently working cross-browser WebRTC would be too much effort to be able to pull off at a given time.
Yeah, I was somewhat surprised by those. "Classes" on domestic flights in the USSR?! And yeah, GUM was (and still is) a department store for Soviet citizens - https://en.wikipedia.org/wiki/GUM_(department_store).
re Lyft: We detect recycled phone numbers, and we'll challenge you (or "not you") for further identification.
Phone recycling has been a much bigger problem for non-fraudulent cases, e.g. you pop-in a new SIM card and naively sign up for Lyft, getting the account of someone else (e.g. a tourist's). Fraudulent takeover of passengers' Lyft accounts hasn't been happening that much — fraudsters have a much easier time stealing credit card numbers than Lyft accounts.
This was done under previous administrations just the same. Telling a CBP officer that you're come to be "paid to lecture" is usually the kind of honesty that doesn't pay off.
CBPs are triggered by the word "work" and "get paid". For example, when you come to volunteer on a WOOOFing farm, you're advised to say you've come for a learning experience rather than "to volunteer" (= CBP hears this as "to work"):
https://wwoofusa.org/how-it-works/#will-wwoof-help-me-get-a-...
I've read similar stories before the current administration. Telling a CBP officer that you're going to be "paid to lecture" is not recommended. This is a kind of honesty that doesn't return a favor.
Does anyone track? I guess as much anyone tracks any "U.S. tax dollars" going to any other US government stuff one doesn't like or agree with. (In other words, probably not much.)
Cellebrite doesn't "target" the U.S. It happily develops forensic tools to target Chinese, U.S.-ian, heck, even Israeli phones (if there were any to speak of).
Furthermore, Cellebrite don't sell exclusively to the U.S. They will sell to Canada, UK, France, Germany or any legit law enforcement agency that has budget. U.S. law enforcement may refrain from buying Cellebrite wares. They might decide to buy from a competitor, like Swedish firm MSAB. Heck, they may decide it's "unethical" to own such tools.
While it might adversely affect Cellebrite's bottom line, I think it will first and foremost adversely affect U.S. police departments' capabilities.
Cellebrite got its start with the UME, a phone memory transfer tool for carriers' (POS and support). Carrier-oriented tools are a major part of its operations, though there have been some talks about spinning this off to a separate company.
Cellebrite gets early access to phones NOT due to its forensics operations, but for UME, since carriers (and that's lots(!) of carriers worldwide) are very much interested in good consumer experience on the devices' launch day.
I actually doubt it's been particularly significant to its forensics operations.
bash: errexit depends on caller's context, will utterly fail you one day: https://lists.gnu.org/archive/html/bug-bash/2012-12/msg00093...