Beyond the API: Navigating Social Threats in Requirements Engineering

TL;DR

As software systems evolve from isolated components into open, autonomous social ecosystems, technical security is no longer enough. This paper argues for a new "Social Layer" in computing, identifying a "new wave" of threats—like fake reputation and untrusted delegation—that require Requirements Engineering (RE) to adopt decentralized adaptation, legal modeling, and proactive trustworthiness management.

Background: The Social Layer

For decades, we have engineered software using technical stacks. However, in modern service-oriented architectures, computer systems act as proxies for human business interactions. The author proposes that the topmost layer of our computing stack should be the Social Layer, governed by concepts like Agents, Roles, Commitments, Trust, and Reputation.

Problem: When Code is Correct but the Business Fails

Traditional RE focuses on preventing technical exploits (e.g., SQL injection). But what happens if a service provider is technically perfect but socially malicious? The paper highlights that current RE methodologies are "inadequate" because they make too many assumptions about the actors in a system. In the real world, actors are autonomous: they can lie about their identity, lose reputation, or delegate tasks to someone you don't trust.

The Anatomy of Social Threats

The paper categorizes eight critical threats that bypass traditional security filters:

• Fake Reporting (T1): Malicious actors gaming reputation systems (e.g., fake eBay reviews).
• Untrusted Delegation (T4): You trust Provider A, but Provider A delegates the task to Sub-provider B, whom you don't trust.
• Dissolved Redundancy (T5): A fascinating insight where you hire two different providers for safety, but both unknowingly use the same backend cloud provider, creating a single point of failure at the social level.
• Incompatible Laws (T6): Services running across borders that unintentionally violate local data or social regulations.

Methodology: The RE Roadmap

To counter these, the author proposes a fundamental shift in how we specify systems:

1. Decentralized Adaptation

Instead of a central controller rerouting traffic, each agent must have its own internal strategy to adapt to social threats. If a partner's reputation drops, the agent should proactively "early-warn" and switch to a different commitment.

2. Rich Service Interfaces

Forget simple REST/SOAP signatures. Future interfaces must include:

• Access Control Policies: Who can see what?
• Compensation Rules: What happens if a commitment is broken?
• Accountability: Who is legally responsible for a failure?

Table I: Aligning the proposed RE solutions with the identified social vulnerabilities.

Experiments & Results: A Strategic Framework

While this is a "vision paper," its primary "result" is the high-level mapping provided in Table I. By aligning specific RE challenges (like Identity Management and Law Representation) with threats (like Fake Identity and Unauthorized Disclosure), the author provides a blueprint for the next generation of trustworthy software development lifecycles.

Critical Analysis & Conclusion

Takeaway

The core contribution is the realization that Trust is not transitive in computing any more than it is in real life. RE must bridge the gap between "Requirements" (what the system should do) and "Regulations" (what the system is allowed to do socially/legally).

Limitations

As a vision paper, it lacks empirical data on the performance overhead of such complex service interfaces. Additionally, representing "laws" in machine-executable code remains a massive hurdle that AI and LLMs might only now be beginning to address.

Future Outlook

This work anticipates the challenges of our modern "Gig Economy" and "API Economy." For practitioners, the message is clear: when designing requirements for a distributed system, you aren't just writing code; you are negotiating a social contract.