Add ARK PubId Plugin by lurymorais (v3.0.0.0)

[lurymorais]

This pull request adds the ARK PubId Plugin (v2.0.0.0) to the gallery, compatible with OJS 3.5.0.x.
Repository: https://github.com/lurymorais/ark-plugin

[asmecher]

Thanks, @lurymorais! I do recommend changing the following...

<version>3.5.0.0</version>
<version>3.5.0.1</version>
<version>3.5.0.2</version>
<version>3.5.0.3</version>
<version>3.5.0.4</version>

...for the semantic versioning form, which is more future-proof:

<version>~3.5.0.0</version>

@bozana, would you mind taking a look at the plugin?

[lurymorais]

Thanks, @lurymorais! I do recommend changing the following...

<version>3.5.0.0</version>
<version>3.5.0.1</version>
<version>3.5.0.2</version>
<version>3.5.0.3</version>
<version>3.5.0.4</version>

...for the semantic versioning form, which is more future-proof:

<version>~3.5.0.0</version>

@asmecher Done!

[lurymorais]

@bozana @asmecher

Hi! Just checking in on this PR. It's been a couple of weeks and I wanted to see if there's any feedback needed.

Also, I wanted to mention that I've released v3.0.0.0 of the plugin with new features and security improvements. Should I update this PR to the latest version, or would you prefer to review v2.0.0.0 first?

Thanks!

[bozana]

Hi @lurymorais, sorry for the delay -- too many PRs to review in the last time...
The version 3 will replace the version 2, right?
In that case I would only take a look at the v3.
Thanks for letting us know.

[bozana]

Security review — this cannot be merged as is

The README discloses the existence of a data-sharing/telemetry system and describes two levels (Basic and Complete). That partial disclosure is noted. However, the code does more than the README describes, and there are critical security vulnerabilities that are unrelated to telemetry.

The plugin.xml entry proposed for the gallery makes no mention of the telemetry or data collection whatsoever — meaning journal managers would install this plugin with zero indication that their journal data will be sent to a third-party server.

What the README does not disclose:

• Every telemetry response (including Basic level) also sends a plugin_ark_token — a persistent authentication credential that the external server uses to pull data from the installed journal. This credential is not listed in the "data shared" table in the README.
• An ark_admin_secret is generated at install time and transmitted to revistacarnaubais.com.br. This secret is never mentioned in the README. It grants the plugin author the ability to call a /ark-api/regenerate endpoint on any installed OJS instance and receive a fresh ark_token — maintaining permanent access to that journal's telemetry endpoint. The journal administrator cannot see this credential, cannot change it, and cannot revoke it short of uninstalling the plugin.
• The README describes a "pull model" where the external server collects data monthly. That monthly schedule is a self-imposed policy by the plugin author, not a technical constraint enforced by the plugin. The /ark-api/telemetry endpoint is publicly reachable at any time by anyone holding the token. Nothing in the plugin code enforces the monthly limit.
• The README describes a "pull model" but the code additionally does a push (curl POST to ark_database.php) on every settings save — data flows both ways.
• The plugin creates two local database tables (ark_journals, ark_sync_log) with no schema migration, causing settings saves to fail on fresh installs.

What a journal manager actually sees during installation:
A journal manager installing this plugin via the plugin gallery sees a short description, clicks Install, enables the plugin, fills in their NAAN and prefix in the settings form, and clicks Save. At that point their journal URL, token, and (if Complete level) contact email are silently transmitted to revistacarnaubais.com.br, and a persistent credential is stored there that cannot be revoked. There is no consent screen, no privacy notice, and no link to a privacy policy shown at any point during this flow. The README with its fuller explanation is on GitHub and is not surfaced during gallery installation.

Critical security vulnerabilities (independent of telemetry):

• save_ajax.php is a standalone PHP file that performs no authentication, no CSRF check, and no session validation whatsoever. It has Access-Control-Allow-Origin: * and accepts both GET and POST requests to write ARK values directly to the database. Any unauthenticated user on the internet can overwrite the ARK of any issue by making a simple HTTP request to this file.
• ArkPageHandler::authorize() unconditionally returns true, bypassing all OJS role and authentication enforcement.
• Token and secret comparisons use !== instead of hash_equals(), enabling timing side-channel attacks against the public-facing API endpoints, which have no rate limiting.
• resolver.php uses LIKE CONCAT('%', ?) for ARK lookups, allowing partial-suffix matching that can redirect to unintended articles.
• save_ajax.php hardcodes a MySQL DSN, breaking PostgreSQL installations.

On the GDPR/LGPD compliance claim:
The README states data is collected in compliance with LGPD and GDPR. There is no link to a privacy policy, no data processing agreement, and no disclosure of data retention periods. Contact emails of journal administrators are collected, which are personal data under GDPR. The claim cannot be verified as stated.

On the stated motivation:
We understand the likely motivation: building a public statistics dashboard showing total ARK usage across the OJS ecosystem, as visible at revistacarnaubais.com.br/ark-telemetry/stats.php. That is a legitimate goal. However, the architecture built to support it goes far beyond what is needed:
A statistics badge showing total ARKs generated requires nothing more than an aggregate count and a plugin version number. The correct and standard approach for this kind of opt-in telemetry would be:

1. Show an explicit consent screen on first configuration, with opt-out as the default
2. List exactly what will be sent — and send only that
3. Have the journal push a minimal payload (ARK count, plugin version) to the statistics server on a schedule the journal controls via a PKP scheduled task
4. The statistics server receives and aggregates numbers, nothing more
5. The journal administrator can withdraw at any time by changing a setting

No persistent credential, no pull endpoint, no ark_admin_secret, no per-journal registration, no contact email — none of that is needed for a statistics dashboard.

Questions for the author:

1. What is the ark_admin_secret used for, and why is it not disclosed in the README?
2. Why does the plugin need a pull endpoint rather than a simple push from the journal?
3. Why is the journal's contact email collected even at the Basic telemetry level (as the code sends it when telemetryLevel === 'public')?
4. What is save_ajax.php doing bypassing OJS authentication entirely?
5. Who has access to the data stored at revistacarnaubais.com.br, and what is the data retention policy?

[bozana]

Hi @lurymorais, during the security review I found some serious problems.

The technical issues like the unauthenticated save_ajax.php endpoint and missing database migrations are fixable.

But, can you answer the questions above and explain the data collection architecture. The plugin registers a persistent authentication credential on revistacarnaubais.com.br for every journal that installs it, creates a remotely accessible endpoint that your server can call at any time to pull journal data, and includes a token regeneration mechanism that gives your server permanent irrevocable access to that endpoint — none of which is disclosed to the journal administrator during installation.
Also, I wouldn't know why this would needed.

I do not think we can recommend this plugin to thousands of journals worldwide without understanding exactly what it does with their data.

[bozana]

Pinging also @asmecher.