Not correct .
RTP is from theclearinghouse and Zelle is from clearexchange.
Zelle came from a mix of banks trying to address only P2P scenarios.
RTP goes beyond to B2C and all other combinations .
Zelle is owned by Early Warning Systems, a wholely owned subsidiary of the top 7 banks in the US. The Clearing House is a joint venture by the top 25 banks in the US.
Clearexchange was purchased by EWS a few years ago.
Maybe we should start to seriously question the value of so long embargos. This is coordinated disclosure; if the vendor refuses reasonable coordination (and it seems Intel does, with such delays, and also because it stills silos the security researchers way too much), then fuck them and publish (probably not immediately but certainly not after a year...)
It seems that broadly the same principles have been found independently by tons of teams. Expecting that well-financed actors have not explored that field and/or not yield any similar result at this point is completely insane.
Meaning, given the high level of technicality required, it's even doubtful that the embargo protected anybody; it might be that no attacker exist (and I postulate will ever exist) that will be simply waiting for 3rd party disclosure before writing its own exploits in that class. On the other hand, typical security providers monitoring threats in the field might not be aware for a long time of the existence of such vulnerabilities.
Now here arguably the first counter measures are similar to those for L1TF, so hopefully sensitive operators would already have disabled HT. However, it is not very cool to not make them aware of this additional (and slightly different) risk during such a ridiculously long period.
Also: does Intel has competent people working on their shit anymore??? They know the fundamental principles; which is speculative execution on architecturally out-of-reach data, followed by a fault and a subsequent extraction via covert channels of un-rolled-back modified micro-architectural state. The broad micro arch is widely known, so do they really expect that 3rd party security researchers won't found all the places where they were sloppy enough to speculatively execute some code on completely "garbage" data? Or were they themselves unable to do a proper comprehensive review, despite having access to the full detailed design (and despite a dedicated team having been created for that)? In either case, this is not reassuring.
I'm not really sure what the question is supposed to be. You could discover an Intel vulnerability and give them a 90 day timeline, or, for that matter, do what the Metasploit founders would have done and just immediately code up an exploit and publish it with no warning. All of these are viable options and all have precedent; it's up to the people discovering the flaws to make their own decisions.
It's particularly weird in this case to suggest that the embargo didn't help anyone, since (1) nobody appears to have leaked these flaws and (2) the cloud providers all seem to have fixes queued up.
Intel claims to have discovered some of these flaws internally, and this is a bug class we've known about (for realsies) for a little bit over a year now, in a class of products for which development cycles are themselves denominated in multiple years, so I'd cut them a bit of slack.
It really depends. Think about it this way, would you rather have an undisclosed vulnerability go untreated and undetected (as far as everyone knows) for an extra year, or suddenly disclose it to the rest of the world before all major interested parties (big companies, chip vendors, etc) have workarounds and mitigations techniques, so actual malicious attackers can exploit it before the countermeasures are ready?
In an ideal world, you should disclose everything and let everyone know so they can take measures against it, but in reality there might be less damage to let the vulnerability continue stay undetected for a few more months while everyone else plans to patch it and release such fixes as it gets disclosed.
I do agree that almost a whole year is, however, a very long time though.
considering the june/july initial reporting, the stacking of evidence to related exploits and the release in may next year it look more like 9 months plus some slacking due to multiple being reported. Does not sound like a "they kept waiting indefinitely" but more like proper due diligence.
That's the same price as C++ (ISO/IEC 14882:2017) and much cheaper than the entire languages codes standard (ISO 639-1:2002, ISO 639-2:1998, ISO 639-3:2007, ISO 639-4:2010 and ISO 639-5:2008).
"Third, adopting an inclination of 17° between the approaching
jet and the line of sight (Walker et al. 2018), the west orientation
of the jet, and a corotating disk model, matter in the bottom part
of the image is moving toward the observer (clockwise rotation
as seen from Earth). "
As a deaf person, I use https://www.ava.me/ most of the time. It allows me to host a group conversation and have speakers labeled if everyone else uses the app but that's a chore to set up sometimes. It's also quite pricey at $30 per month and some months I use it for less than a hour. It can voice what you type if you want, but I normally voice for myself. I also used to use Keep Notes & the 'mic' icon in a pinch, but that would turn itself off if it didn't pick up any speech in some time.
Action may be required to prevent your Let's Encrypt certificate renewals from breaking.
If you already received a similar e-mail, this one contains updated information.
Your Let's Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days. Below is a list of names and IP addresses validated (max of one per account):
example.com (x.x.x.x) on 2018-12-05
TLS-SNI-01 validation is reaching end-of-life. It will stop working temporarily on February 13th, 2019, and permanently on March 13th, 2019. Any certificates issued before then will continue to work for 90 days after their issuance date.
You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.
Our staging environment already has TLS-SNI-01 disabled, so if you'd like to test whether your system will work after February 13, you can run against staging: https://letsencrypt.org/docs/staging-environment/
Our forum has many threads on this topic. Please search to see if your question has been answered, then open a new thread if it has not:
https://community.letsencrypt.org/
We would really suggest using certbot-auto instead because it will create a venv for you so that you don't get version conflicts elsewhere. (It does use pip behind the scenes, but in a venv.)
