This has existed for every web engine since time immemorial, calling out Safari is misleading. Firefox calls them "site interventions" and Chrome calls them "patches" rather than Safari/WebKit's "quirks".
Federal Rule of Evidence 706 already provides for court-appointed experts which report to the court and the parties and for whom the costs are shared. But a battle of the parties' experts can allow the jury to weigh the credibility of the opposing opinions after the court has vetted them. J&J can afford the right experts, and the collective resources of plaintiffs (and the investment of their counsel) can easily match this.
My recommendation: use xSearch for iOS! It's a Safari extension app so no need to use a nonstandard browser. I use it to give me custom !bang searches for various databases, but it has an option to override the Safari default search engine. It works very reliably on iOS and Mac.
Congress's Commerce Clause power in the Constitution is notorious for being very broadly interpreted in the modern era. Here, Congress is either regulating a "channel" of interstate commerce (the internet) or intrastate economic activity that interferes with interstate commerce (local ISP rules making nationwide ISP business more burdened).
One of the features DocuSign charges a lot of money for is batch envelopes, like uploading a CSV to fill out fields and send to different recipients (basically Mail Merge). Is this something that could work in DocuSeal?
I was planning to add this week a feature to download csv or xlsx with all the data from submitted documents (the person that posted this link on HN somewhat spoiled the release - it was not be posting this link and wanted to wait just a bit )
But I’m sure this can work the other way around - it should be easy to make it possible to import contacts from csv to collect signatures and data from the PDF submissions form in batches.
Our product Bulksign https://bulksign.com does this, the name of the product is directly inspired by that feature (sending same documents for signature to hundreds of recipients).
The ESIGN Act makes no distinction in the US between whether you cryptographically sign or digitally draw, etc., defining a signature as "an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record."
- "electronic signatures", which can be any electronic data used to sign, like a drawn signature
- "advanced electronic signature" (AdES), usually a type of digital signature (XML-DSig, PDF signature, etc.)
- "qualified electronic signature (QES), which is a digital signature created by a certified signature device
QES is legally equivalent to a "wet signature", but in my experience rarely used because of cost. AdES is much more common for high-trust scenarios like loan applications. For low-trust like package delivery, a signature (or smiley) drawn on a touch device will usually do.
AdES is mostly an technical standard that specifies how to use existing PKCS and IETF standards to produce eIDAS conforming signature, timestamp or “seal” (ie. timestamped signature) and how that should be mapped onto CMS (CAdES), XML-Signature (XAdES) and PDF (PAdES). How legally binding the result of that process is then depends on things like QSCTs, their LoA used in that and such things. And then there are various carveouts, for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
> for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that)
AFAIK that is not true. In CZ national law, there is also recognized electronic signature (RES, "uznávaný elektronický podpis"), which may be either QES (per eIDAS, "kvalifikovaný elektronický podpis"), or just AdES based on certificate from qualified CAs (per national law, "zaručený elektronický podpis, založený na kvalifikovaném certifikátu").
If you use QSCD to generate CSR and get it signed by right CA, you get QES, but if you use just 'openssl req' to generate CSR and get it signed by right CA, you get RES that is not QES.
The point is that the CA has no way to determine that the CSR was generated by Qualified Device and will just sign it. My view of all the talk about Qualified Devices in eIDAS exists mostly to force QCAs to use normal enrollment process with CSRs instead of their random home-grown processes that result in PKCS#12 file containing private key generated who knows where and who knows how.
