CCFrank: the conference rank badge that appears inside your search results

A rank label next to the venue name

The extension, called CCFrank, displays the China Computer Federation recommended rank of international conferences and journals in the search results of dblp, Google Scholar, Connected Papers, Semantic Scholar and Web of Science. There are screenshots in the readme for each of the first four plus Web of Science, which is a good way to see what the annotation looks like in practice.

The idea is small and the execution is the interesting part. A researcher in a field where the federation list is the informal currency of the seminar room wants to know, at the moment they are looking at a search result, whether the venue they are considering is a top tier venue, a second tier one, or unranked. The extension does not add a panel or a sidebar. It marks the result list.

Two details in the readme are worth noting. The list of sites includes Connected Papers and its mirror sites, which suggests the author had to handle the fact that some of these services are reachable under more than one domain. And there is a warning, with an emoji, that you should refresh the page if the ranks do not show up on Connected Papers, which tells you the injection is not always reliable on that site.

The extension is available from the Chrome Web Store, the Firefox add-ons site and the Microsoft Edge add-ons store, and the readme recommends installing from the store rather than from source, which is the usual advice for an extension that needs permissions on academic sites.

The data is a yearly snapshot, and it has a maintenance cycle

The ranking data comes from the China Computer Federation's recommended list of international academic conferences and journals, and the changelog shows how that dependency is managed.

The version 4.6.0 entry, dated in April 2026, updated the extension to the 2026 version of the federation's catalogue and fixed a large number of conference and journal full names. The version 4.5.2 entry added expanded and preprint categories, and the version 4.4.2 entry corrected the reported URL for one journal and updated another venue's entry.

So the data is a copy of an external document with a publication schedule, and the extension is only as current as the last refresh. The readme even links the federation's catalogue page directly in the changelog, which is a nice touch for anyone who wants to check a rank independently.

The full-name corrections in 4.6.0 are worth a second look, because they reveal the matching problem. The extension matches a venue string in a search result against a table of known venues, and venues appear in search results under many spellings and abbreviations, so a list that is complete enough to be useful is a list that needs constant correction.

The same release also mentions code quality fixes, specifically a memory leak and a problem with modifying the local storage during iteration, which is a reminder that a browser extension doing a lot of DOM work has the same failure modes as any long lived program.

The per-site scripts are where the maintenance happens

The changelog is a map of the extension's internals, and it is more informative than it first appears.

The source tree holds a separate script for each site, and the names appear throughout the history: the Semantic Scholar, Web of Science and dblp scripts, a shared rank fetching module, and a Connected Papers script. The version 4.5.3 entry, from February 2026, fixed a memory leak caused by repeated event listener binding in three of those site scripts at once, which is what happens when the same pattern is copied into several files.

The same entry lists the smaller repairs: a bug where one site's data structure was used in the Semantic Scholar script, a comparison written with the wrong operator in the rank fetching module, several undeclared global variables, a hardcoded three-second delay in the Connected Papers script that was removed for responsiveness, dead code and an unused CSS class, and a change from the older variable keyword to the newer one for style consistency.

Earlier entries show the caching model. The 4.4.0 entry, from November 2023, fixed repeated queries against the dblp application programming interface, and introduced storing data persistently in the browser's local storage with a default expiration time of one day, along with a rewritten rank fetching function that caches and reuses query results. The 4.3.3 entry added an application token to the queries, for debugging only.

And the 4.4.1 entry, from December 2023, is the one that explains the refresh warning. The extension was refactored to process existing search results as soon as the page loads, and to use a mutation observer to handle entries that appear later without marking them twice, along with fixes for a case where the total rather than the sent count was iterated, an undefined venue, and a cache that ran into the storage quota error.

Installing it, and the permissions it asks for

There are two installation routes and the readme is clear about which one it prefers.

Installing from the store is the recommended path, and the steps are the usual ones: find the extension in the Chrome Web Store, the Firefox add-ons site or the Microsoft Edge add-ons store, and click the button to add it to the browser. The readme then names the permissions, which is worth reading before you click: the extension needs to read and change dblp, Google Scholar, Connected Papers and its mirror sites, and the browser will ask you to approve that.

Loading from source is the second route, for anyone who wants to read the code or patch it. You clone the repository into a directory, open the extension management page by navigating to the extensions URL in the browser, enable developer mode with the toggle next to it, and then click the load unpacked button and select the directory that holds the extension. The readme notes that the same page can be reached from the browser menu, by hovering over more tools and selecting extensions.

The permissions deserve one more thought for anyone installing this on a work machine. The extension is allowed to change the pages of the search sites you use for research, which is exactly what it does and nothing more, but it is the kind of permission that an institution's browser policy may still ask about. The privacy policy file in the repository is there for that conversation, and it is the first thing to read before installing an extension with page modification rights on the sites you use daily.

A small project with modern tooling and a long gap

The project file is a good example of a small extension that has adopted current tooling without turning into a build system.

There are no runtime dependencies at all, which is what you would expect from a browser extension that injects a few labels into a page. The development dependencies are a short list: Husky for the git hooks, lint-staged for staged file handling, Prettier pinned to a specific version, and a git formatting tool. The scripts section has a single entry, the prepare hook that installs the Husky hooks, and the lint-staged configuration runs Prettier over every file with unknown types ignored.

The repository layout matches the shape of the project. A directory per site script and a directory for the shared rank library, a stylesheet directory, a data directory holding the ranking information, the manifest and the entry script at the root, an icon directory, an image directory for the readme, and a locales directory for the translations. There is also a contributors configuration and a privacy policy file, the latter being a sign the author expects the extension to be installed on machines that are not their own.

The release rhythm is the one thing to note. Versions 4.4.2 and 4.4.1 came in late 2023, 4.5.0 through 4.5.2 in late 2024, and then 4.5.3 through 4.6.1 between February and May 2026, with the last push on 2026-05-26 and a release the same day. So the project is alive and shipping fixes, but it is a hobbyist cadence rather than a continuous one, which for an extension that depends on the markup of five different search sites is a reasonable trade.

Editorial conclusion

Adopt CCFrank if you are a researcher who publishes in the venues the federation ranks, and you want the rank visible next to the venue name rather than in a spreadsheet you maintain yourself. Do not adopt it as a source of truth for the ranking itself, because the extension ships a copy of a yearly list that the maintainers refresh when the federation publishes a new version. Before you rely on a label, check which version of the list the extension is carrying, and if the rank does not appear on a page, reload it, since the README warns that results already on screen can be missed without a refresh.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. WenyanLiu/CCFrank4dblp on GitHub