On Sun, Feb 16, 2025 at 12:20 PM Pierre Barre <[email protected]> wrote: > > > > * It requires JS to do anything useful. > > These days, most browsers support JavaScript. You might want to give one a > try! ;-) > > Joking aside, I get where you're coming from, but I don't think this is a > hill worth dying on. That battle is mostly lost. Even if I personally > preferred the way the "old web" used to work, the industry has largely moved > on. Sticking to the old approach often means reinventing the wheel at every > step, and I have more productive things to do. > > I also think having a thin JS client as a website allows to design APIs in a > sensible way as they are used first hand.
One counterpoint to JavaScript-enabled sites: I don't want JavaScript running on login pages. JavaScript can egress credentials through the DOM. Consider, there's a httponly flag to protect cookies from JavaScript, but nothing to protect the precursor credentials from JavaScript. Maybe the web needs a HTML tag for secure credential entry that only the browser handles (and sends to the server). As a datapoint, checkout all the unconstrained JavaScript that runs on Alight's login pages. Alight is HR-as-a-Service and provides health and retirement recordkeeping and benefits. Searching the web finds a company called RTX that uses them; see <http://www.yourtotalrewards.com/rtx>. There are trackers, traditional analytics and AI analytics scraping the page. The promiscusity instills no confidence in me. Alight has serious data security problems. They are being investigated for an undisclosed/unreported data breach; see MARTIN J.WALSH, Secretary of Labor vs ALIGHT SOLUTIONS LLC (No. 21-3290 (7th Cir. 2022)). The company tortures users with {username, password, PIN, 3-each security questions}-tuples. And they do all the dumb things with passwords, like composition and complexity requirements; and gratuitous rotations. The company _does not_ support YubiKeys. > > * The search box only takes subdomains, not other identifiers I'm > > commonly interested in (like SPKI fingerprints). > > You can currently do this by modifying the URL directly, for example: > > https://www.merklemap.com/certificates/ba7924eedf9c95809bc4f46dce070b946560054e1ad7494e210627bfc57b358a > > Not the best UX, I'll admit. > > > * You can't see any details about certificates without an account. > > > > * Only a subset of search results are apparently available without a > > paid account. > > Merklemap.com isn't sponsored, and the operating costs are substantial. The > dataset is massive— even well-funded organizations struggle with the scale of > this kind of data, as seen with > https://letsencrypt.org/2024/03/14/introducing-sunlight/ even though CT log > operators only store a subset of the data, and only provide a very limited > set of APIs. > > Merklemap, on the other hand, is exhaustive. It contains the full history of > certificate transparency since its inception. The main database has just > under 100 billion rows, spans dozens of terabytes on NVMe storage, and the > search index is massive. The system is able to ingest around 100,000 > certificates per second (which is useful to handle backlog). That kind of > scale isn’t free to operate. > > I strongly believe that for the health of the ecosystem, services like this > need to be self-sustaining. A funded model ensures they can remain available > and continue improving. Jeff -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAH8yC8m1ucwP5wR4VCVfOCsikeL0SkGNbxO%3DWY79T-0ebU8jMQ%40mail.gmail.com.
