I've been on hundreds of calls for both and have personally had far more issues with zoom than google. I also prefer Google's UI and security model, and Google's pricing is better for companies using gmail.
Google's advanced security is a good example of an actual implementation of fido2 where they've had to deal with real world threats and device usage. They require multiple fido2 devices (for dealing with the lost/damaged problems).
Compromise of FIDO2 devices is particularly interesting though. Specialized hardware like a yubikey rather than software based fido2 might help here, but that still leaves theft as a wide open vector. If theft is a risk for your use case, https://www.yubico.com/blog/getting-a-biometric-security-key... could be an interesting solution or using secure hardware on your phone behind a lockscreen. Also having a password (in addition to webauthn) might be good enough for you to slow down an attacker enough for you to disable your compromised device (using another fido2 device to authenticate).
Looks exciting! It is kind of disappointing the AI generated main example on their home page has what appears to be a url encoding bug in it though (in text=${text}, text should be url encoded before being passed to fetch).
~1/5 of Apple's Services revenue comes from having google be the default search ($9-10B per year), so I wonder if this new search will coincide with them ramping up their own search ads business [https://9to5mac.com/2019/11/15/apple-ad-revenue/]
This seems to predate FIDO2. https://solokeys.com/ would be a better option if you prefer separate keys for each site (via FIDO2) and open source hardware.
I agree that short term providers will likely take in less money with a "Medicare for all" solution, but I think the problem presented by this blog post is overstated/misrepresented:
1) The "Over 65" demographic visits the hospital more than other demographics so comparing raw number of people is an apples to oranges comparison (65+ somewhere between 3-10x more likely to utilize an inpatient stay, https://www.hcup-us.ahrq.gov/reports/statbriefs/sb235-Inpati...)
2) Roughly half of all administrative costs in US hospitals are associated with billing. Administrative costs are lower in single payer systems because hospitals don't need to bargain and coordinate billing with multiple parties. Doctors will still be needed by hospitals, but hospital workers/sales people/VPs who bargain with insurance companies will be less necessary. This is a significant percentage of hospital expenditures [https://www.americanprogress.org/issues/healthcare/reports/2...] Administrative staff seem much more likely to see paycuts or staffing cuts rather than necessary staff like doctors/nurse.
ITP 2.1 also already says it will block cookies of this type if it matches Safari's completely non-transparent ML model for "tracking cookies". Also Chrome pushed back the release date of this new default from end of August 2019 to February 2020 and the bug has been "fixed in a non-yet released version" of Safari since early June (safari is really slow to release security patches).
Apple's search ads are projected to be one of the largest online advertisers in terms of ads revenue in 2020 (they have larger advertising revenue projections than both snap and twitter). Device sales in general are dropping so they are expected to continue to invest in this area of their business. Given that Apple is a large organization known for their lack of transparency, I would be very surprised if they weren't already doing shady things with user data for targeting purposes.
It's a bit disappointing their demo doesn't appear to leverage certificate transparency logs as a source of truth for which certs are out there and instead relies on pinging the server directly
Prepared statements tend to be the best answer for most cases which is similar to the approach you describe but is natively supported by most SQL dialects and also improves performance.
In my experience, many developers and even experienced security engineers can fail to give this answer though.
There is a huge monetary and PR incentive for the fossil fuel industry to publish research that proves "there is no issue" in regards to climate change. The energy industry is where the money is and your conclusions seems to be the exact opposite of this reality. While the field of climate science overall has gotten somewhat larger and more funding due to the strong evidence that climate change is going to cause problems for human life, any individual scientist who could prove climate change is not happening or won't affect human life in the foreseeable future has every incentive to do so and would get plenty of grant money.
Seems like a bit of an oversight that they are including third party tracking scripts like googletagmanager.com in the same context as the javascript doing encryption. If you need user tracking, at least put the tracking scripts in an iframe sandbox or something that can't accidentally grab the keys from the URL fragment and send them off to google.
Also they do call out that URL fragments get stored in browser history which is a big risk, but they should also mention that many browsers automatically "sync" history across devices (so keys will get sent to a cloud if you aren't using incognito/private browsing).
The "generic NFC" support you refer to is read only which means that protocols like U2F still don't work so usability of U2F for iPhone users is still not there (without bluetooth keys which have their own problems).
No this is an issue with Newegg. They had the option to either "Begin collecting sales tax from Connecticut customers going forward and send that money to the state, or turn over the records."
They chose to give their records to the government which causes a major hassle for those users (and increases the likelihood that those records get breached, infringing on users' privacy). They did this at the expense of potentially hurting future Newegg sales because they'll have to honestly show users the tax while they are buying things, rather than having the government hunt down users later on.
Do you have any more details around such an attack?
The only HSTS bypasses I am aware of that were possible with control over DNS were dependent on browser vulnerabilities that have been long since fixed or required the domain to not be cached or preloaded (which effectively means you'd only be able to attack first time visitors on sites that have not implemented preload who are clicking on an http link)
Chrome is listed as impacted due to javascript being able to read memory from outside the browser sandbox.
"In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it." - from the spectre paper