--- title: 'OneDrive: Cloud Storage and Collaboration' url: https://www.emergentmind.com/topics/onedrive type: topic --- # OneDrive: Cloud Storage and Collaboration Microsoft OneDrive is an online storage solution providing both file storage and sharing, exposed to users through synchronized desktop folders and multiple clients, and used in research as a substrate for distributed computing, enterprise content management, forensic acquisition, and secure sharing. In the literature it appears both as a mainstream cloud storage service and as a component within Microsoft 365 collaboration workflows; the term should also be distinguished from the unrelated autonomous-driving framework titled “OneDrive” [1907.03688] [1603.06542] [2506.17317] [2604.17915]. ## 1. Service model and ecosystem position OneDrive’s core user-facing model is the synchronized folder. In cyberinfrastructure settings, this is treated as a major usability advantage: users can “simply copy input files on their desktop to the OneDrive folder and it is made available,” while retaining familiar file access and editing within the operating-system file browser. The same research emphasizes sharing, multiple clients across platforms, and the fact that many researchers already have access to OneDrive through institutional Office 365 subscriptions [1907.03688]. In comparative cloud-storage studies, Microsoft OneDrive—referred to as SkyDrive in older work—is analyzed alongside Dropbox, Google Drive, Amazon CloudDrive, Box, and SugarSync as a representative consumer cloud service. The implementation choices attributed to OneDrive include support for chunking, the absence of reported cross-file deduplication, and no server-side storage compression: the measured storage size reduction is 0% on both 50 MB and 100 MB datasets. The same study also attributes synchronization overhead to the fact that OneDrive “has to contact many Microsoft Live services,” and notes that in bulk uploads it waits for an application-layer acknowledgment after each file [1602.06246]. Within Microsoft 365, OneDrive is modeled as a business collaboration platform organized around shared files and folders. The role structure used in the permission-management literature is owner, editor, commenter, and viewer; add-ons in this setting include OAuth apps built on Microsoft Graph, Office add-ins, and Teams apps that interact with content backed by OneDrive or SharePoint document libraries. This framing places OneDrive not only as storage, but as a central coordination substrate for multi-user resource management [2506.17317]. ## 2. Workflow integration and programmatic access A prominent research use of OneDrive is as an input-distribution mechanism for HTCondor-based distributed computing. In that architecture, users place input data in OneDrive, jobs declare a need for OneDrive OAuth credentials, HTCondor’s CredMon daemon performs a one-time browser-based authorization and manages token acquisition and renewal, and short-lived credentials are transferred to the execution node before the job begins. On the worker, a lightweight statically compiled Go client reads the JSON token from `_CONDOR_CREDS/onedrive.use`, inserts the access token into the `Authorization` header, and downloads content directly from OneDrive via the Microsoft Graph API over HTTPS. The Azure registration and submit-host configuration are explicit: the redirect URI is `https:///return/onedrive`, the scope is `Files.ReadWrite.All`, and the submit host uses `ONEDRIVE_CLIENT_ID`, `ONEDRIVE_CLIENT_SECRET_FILE`, `ONEDRIVE_AUTHORIZATION_URL`, and `ONEDRIVE_TOKEN_URL` [1907.03688]. This integration is motivated primarily by usability rather than by peak transfer performance. The scheduler, rather than the user, handles acquisition, renewal, and secure transfer of credentials, so users do not manually copy privileged keys with jobs. The worker-side client is a single static binary, and the paper reports that no issues were observed during experiments and all OneDrive downloads completed successfully. The same study argues that this is particularly relevant for smaller groups or individual users who lack the infrastructure and expertise required to operate specialized data-distribution stacks [1907.03688]. OneDrive also appears in recent work on automated workflow generation, where it is the target of cross-service orchestration from Outlook. The case study uses Dynamic MCP to discover operations such as folder creation and file upload, then grounds tool behavior by probing raw outputs before scaling. The recommended procedure is Sample → Inspect → Codify, with explicit warning that enterprise APIs often return Graph-style envelopes such as `{"@odata.context": "...", "value": [...]}` rather than bare lists. The same paper couples this with Linear State Anchoring via `write_todos`, idempotent folder creation, and `asyncio.gather` for concurrency, but does not provide quantitative benchmarks specific to OneDrive workflows [2512.20278]. ## 3. Performance behavior and storage heterogeneity Empirical studies depict OneDrive as highly dependent on workload shape, client behavior, and network context. In a six-service comparison focused on storage heterogeneity, OneDrive is the slowest service for a single-file 15 MB download at approximately 50 seconds, and its bulk-data download time for a 10 MB heterogeneous set is approximately 15 seconds. The same study does not report numeric upload or synchronization values for every case, but it attributes OneDrive’s download and synchronization penalties to control signaling overhead and reports 0% storage-size reduction on both 50 MB and 100 MB datasets, in contrast to Box, Dropbox, and SugarSync [1602.06246]. A later packet-level study of multimedia uploads over Wi-Fi and LTE reports that OneDrive shows variable behavior and a persistent bimodal packet-size distribution. Under Wi-Fi, the measured session lasted 96 seconds, contained 54,028 packets, averaged 557 packets/s, had an average packet size of 803 bytes, and achieved 3.578 Mbps average bandwidth utilization; 45.66% of packets were small (50–99 B) and 52.19% were large (1,450–1,500 B). Under LTE, the same study reports OneDrive paths of 24 hops to `onedrive.live.com / 13.107.139.11`, average delay above 100 ms, jitter around 9–10 ms, packet-loss windows around 5%, TLS 1.3 traffic, and bursts of retransmissions and out-of-order packets. The authors characterize OneDrive as more sensitive to mobile-network fluctuations than Google Drive and Dropbox [2510.25079]. In distributed-computing measurements, OneDrive’s transfer behavior is likewise site-dependent. In Open Science Grid experiments, OneDrive was always slower than HTTP or StashCache at Syracuse, faster than StashCache but slower than HTTP at Colorado, much better than both HTTP and StashCache for the 2.3 GB file at Bellarmine, and comparable to HTTP and StashCache at the University of Chicago. Repeated downloads were performed to test for caching, but no caching effect was observed. The aggregate summary is that OneDrive performed better than StashCache on average but worse than HTTP, with strong dependence on site connectivity and network path characteristics [1907.03688]. A plausible implication is that OneDrive’s research profile is less that of a uniformly optimized high-performance data plane than of a general-purpose storage substrate whose practical value depends on deployment context. The measurements support that interpretation, but they do not reduce to a single ranking across all environments. ## 4. Security, sharing, and permission boundaries OneDrive has been the subject of direct security criticism in the context of short capability URLs. Research on `1drv.ms` links showed that the underlying token space was small enough for brute-force scanning: Bitly-style tokens use an alphanumeric alphabet of size 62, giving a 6-character space of \(62^6 \approx 5.7 \times 10^{10}\). In a random sample of 100,000,000 six-character Bitly tokens, 42,229,055 valid mappings were found. Among sampled tokens, 3,003 six-character URLs and 25,594 effectively six-character seven-character URLs pointed to OneDrive; prior to Microsoft’s March 2016 changes, a single discovered short URL could expose `cid` and `authkey`, allowing traversal of additional shared resources in the same account. The same study found that approximately 7% of discoverable OneDrive accounts had at least one folder shared with edit capability, creating a malware-injection vector because synchronized clients would automatically pull attacker-supplied content [1604.02734]. The paper’s attack model is structurally important. OneDrive sharing by link is treated as capability-based: possession of `authkey` can confer read or edit rights without further authentication. Before the platform change, automated traversal from one short URL to an account root page expanded exposure well beyond the originally shortened target. Microsoft subsequently removed the “shorten link” option in OneDrive and changed the root-page behavior so that `cid` and `authkey` no longer yielded a directory listing, but previously generated short URLs remained active [1604.02734]. In the team-workspace literature, OneDrive is analyzed through a different lens: the interaction of add-ons with platform permissions. The formal model imposes two checks on add-ons—OAuth permission scope checking and user role permission checking—and the platform overview marks OneDrive as potentially vulnerable in principle to OAuth permission escalation and user-role permission escalation, while robust against add-on-driven sharing-permission escalation. Crucially, that paper does not empirically test OneDrive APIs; the designation is model-level rather than a validated OneDrive exploit corpus [2506.17317]. ## 5. Forensic acquisition and evidentiary completeness Forensic work treats OneDrive as a case where client-side acquisition is inherently incomplete. A local client functions as a cache, not as an authoritative mirror: selective sync means that not all files are present locally, local artifacts usually expose only the latest version rather than revision history, and cloud-native artifacts remain problematic. The proposed remedy is API-based acquisition using the officially supported service interface, which is described as formally documented, stable, reproducible, and closer to the provider’s authoritative state than reverse-engineered client artifacts [1603.06542]. The proof-of-concept tool `kumodd` implements this approach for OneDrive through a dedicated provider driver. Authentication uses OAuth2; the user visits the provider URL, signs in, grants access, pastes the returned code into the CLI, and the resulting access token is cached in `/config` as a `.dat` file. The OneDrive driver supports listing, filtering, downloading, and revision enumeration. Discovery results are recorded as CSV, per-file metadata is preserved in JSON under `/downloaded//metadata/`, and the acquisition log records `TIME(UTC) APPLICATION USER FILE-ID REMOTE PATH REVISION LOCAL PATH HASH(MD5)`. Revisions are downloaded automatically and saved with timestamp-prefixed filenames [1603.06542]. The evidentiary value of this design lies in completeness and provenance. Folder structure is mirrored locally, revision counts are visible during listing, and provider metadata—when exposed—can include cryptographic hashes. At the same time, the paper is explicit about limits: it does not claim acquisition of OneDrive recycle-bin contents, sharing ACLs, or Office Online cloud-native snapshots. In throughput measurements using 1 GiB test sets from EC2, OneDrive averaged 18:21 and 0.95 MB/s, comparable to Box and slower than Google Drive and Dropbox in that specific setup [1603.06542]. ## 6. Cryptographic protection layers and enterprise use Several papers treat OneDrive not as a trusted security boundary but as an opaque storage and synchronization substrate over which stronger cryptographic guarantees must be layered. In the enterprise end-to-end-encryption model, OneDrive is the `SERVER`: file content is encrypted on the client, per-user access metadata is embedded into the file itself as encrypted user blocks, and only ciphertext is stored or transmitted. The design uses a Curve25519 PKI key pair, a per-user `K_master`, and per-file keys consisting of a File Encryption Key (FEK) and File Signature Key (FSK). Read permission is tied to FEK possession, while FEK+FSK yields write capability. To hide identities and privileges, user blocks are encrypted under ECDH-derived symmetric keys and padded to equal length; rollback attacks are addressed through per-directory file-header freshness files and a hash-tree mechanism signed with `K_master`. The same analysis emphasizes residual leakage—filenames, file sizes, timestamps, and access patterns remain visible—and notes that server-side features such as Office Online preview or real-time coauthoring are incompatible with ciphertext-only storage [2006.01264]. This enterprise scheme also reworks recovery and escrow. `K_master` can be recovered from a password-protected server copy or via distance-bounded social recovery in which the secret is split into \(n\) shards with threshold \(k\), distributed to nearby peer clients over channels such as BLE or NFC, and reconstructed only after collecting \(k\) valid shares. Escrow stores encrypted shards rather than plaintext master material, so even a compromised server or escrow service cannot unilaterally decrypt OneDrive-hosted content. The paper does not provide formal proofs or performance benchmarks, but it does specify an Android proof of concept for the shard exchange [2006.01264]. A distinct overlay system, Protbox, operates one layer above OneDrive’s own clients and APIs. Protbox never calls OneDrive directly; instead it pairs a local plaintext “Prot Folder” with a locally synchronized OneDrive “Shared Folder.” Files copied into the Prot Folder are encrypted before being written into the Shared Folder, and files arriving from OneDrive are validated and decrypted locally. A random Pair Key protects each Pair, filenames are encrypted with AES-ECB and a modified Base64 alphabet, integrity is enforced by storing an HMAC over ciphertext, and key exchange between collaborators is implemented through special request and response files placed in the OneDrive-synchronized folder and signed with national eID tokens via PKCS#11. The same system keeps cleartext backups in its private registry, renames conflicting updates rather than overwriting them, and treats revocation as a OneDrive sharing-policy matter rather than as automatic cryptographic rekeying [1501.03139]. Across these cryptographic overlays, a consistent pattern emerges: OneDrive supplies storage, propagation, and collaboration reach, while confidentiality, integrity, rollback resistance, and access semantics are moved to client-controlled cryptographic mechanisms. This suggests a division of labor in which OneDrive remains operationally central but not cryptographically authoritative. Source: https://www.emergentmind.com/topics/onedrive