devinl

It wouldn't always be a mistake. Moderna stock is significantly lower than it was in 2021 so the CEO could be harvesting losses.

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.

Do economic experts still think trickle down/supply side economics are a good idea? It seemed to be a controversial issue among economists in the 70s and 80s. From what I could find, the modern consensus among economists is that tax cuts for the wealthy isn't effective at increasing GDP. (see https://en.m.wikipedia.org/wiki/Supply-side_economics http://www.igmchicago.org/surveys/tax-reform-2 http://www.igmchicago.org/surveys/tax-reforms )

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

In the technical details, he has a link to the open source on github. Here's the js that's actually doing the preloading: https://github.com/instantpage/instant.page/blob/master/inst...

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.

This article has more written about monetary incentives of climate scientists: https://arstechnica.com/science/2016/05/if-climate-scientist...

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)

Android: https://source.android.com/security/

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

Some interesting arguments suggesting what he is saying is at least partially wrong: https://www.reddit.com/r/AskHistorians/comments/74penu/walki...

So from reading this over it sounds like you are enabling an endpoint on your site with both CSRF protection enabled that also sends CORS headers to allow for cross origin ajax calls. This could be a workable solution for cross domain calls on the same subdomain (like a.example.com and b.example.com but not malware.com). Since you can scope cookies to domain suffixes, you can have a csrf cookie that can be read from javascript from a number of subdomains and included in a header but can't be read from other domains. Same origin policy prevents domains from reading cookies not scoped to their domain so this should not have any security issues. Note that if you care about confidentiality, you would have to put your CSRF protection on the GET requests (which is a bit abnormal) with CORS since Access-Control-Allow-Origin allows for reading data cross origin (in addition to making requests).

On the other hand, it seems like https://en.wikipedia.org/wiki/Same-origin_policy#Security_Ap... is flawed and should be fixed. The section seems to be directly describing a CSRF attack and then saying CSRF protections are not effective which doesn't make sense.

As stated in the article, they need to reach 11 billion miles to get the confidence level they are looking for. So extrapolating this, it would take 5500 cars a decade of round the clock testing to actually meet the guarantees they need (90% safer than human driven at a 80% confidence level). You still could do it in parallel; it'd just require a lot of test cars.

One part that is unclear is that the 11 billion mile requirement doesn't specify urban conditions and the 2 million mile per decade estimate does. So there might be some errors there.

One thing that is kind of unique about this vulnerability is that users can actually prevent attacks from happening by checking the permissions on an untrustworthy app because google has permissions controls built in for the features that are being abused here.

The heart of this vulnerability is more in that these settings aren't clear on their implications and there are bad defaults. Disclosing to users seems to be a responsible thing to do since users can prevent an attack on their own device (especially given google's response of "working as intended").