Frequently Asked Questions

When you choose to encrypt a file in the current version:

1. A unique, strong password (File-Specific Password) is randomly generated specifically for that file by the application running in your browser.
2. The file content is encrypted in your browser using this File-Specific Password with AES-GCM-256 encryption.
3. The encrypted file content is split:
   • The main chunk is stored as a .json file (containing the encrypted data, salt, and IV) on your Google Drive (in the configured folder).
   • A small trailing fragment is stored as a _frag.json file on your Microsoft OneDrive (in the configured folder).
4. The File-Specific Password itself (along with its source file ID for reference) is stored within a _pwd.json file on your Microsoft OneDrive (in the configured folder).

To decrypt and view a file, the application will need to access Google Drive (for the main encrypted chunk, salt, and IV), and Microsoft OneDrive (for the fragment and the _pwd.json file containing the File-Specific Password).

This means an attacker would currently need access to both your Google account and your Microsoft account to gather all components and decrypt an encrypted file. The application itself has zero knowledge of your cloud account passwords; it uses secure OAuth 2.0 for authorization.

Upcoming Security Enhancement: A future update will introduce a "Session Master Password." This user-provided password will be used to encrypt the _pwd.json file (containing the File-Specific Password) before it's stored on OneDrive. This will add another layer of security, requiring an attacker to also know your Session Master Password, in addition to gaining access to both your cloud accounts.

This application uses OAuth 2.0 to connect to your Google Drive and Microsoft OneDrive accounts. This is a standard and secure industry protocol.

• Zero Knowledge of Your Passwords: The application never sees, asks for, or stores your actual Google or Microsoft account passwords. You authenticate directly with Google or Microsoft.
• Granular Permissions: You grant the application specific, limited permissions (e.g., to read/write files in its designated folders). You can revoke these permissions at any time from your Google Account settings or Microsoft Account settings.
• Leverage Your MFA: If you have Multi-Factor Authentication (MFA/2FA, like authenticator apps, security keys, or SMS codes) enabled on your Google and/or Microsoft accounts, that protection automatically extends to this application's access. The OAuth flow will require you to complete your MFA steps if prompted by Google/Microsoft. This significantly enhances the security of your cloud accounts against unauthorized access.
• User Control: You are in full control of the authorization.

Configuration is necessary to allow the application to connect to your cloud accounts for storing and retrieving files. You can customize the Client IDs and folder names used by the application via its Settings page.

Configuration is necessary to:

• Allow the application to store an index of your file structure (metadata) on your Google Drive.
• Allow the application to upload actual files (or large encrypted chunks containing data, salt, and IV) to your Google Drive.
• Allow the application to upload encrypted file fragments and the File-Specific Passwords (within _pwd.json files) to your Microsoft OneDrive.
• Enable features like sharing (if implemented via cloud links) and ensuring your data is accessible/recoverable across sessions/devices.

Without configuration (or if the default public IDs are used with many users), the application will work locally, but cloud-dependent features, especially encryption backup and restore, will be unavailable, severely limited, or might conflict with other users if using shared public developer credentials.

It is highly recommended to create your own Client IDs for Google and Microsoft for private and reliable use.

You can set two main pieces of information via the application's Settings page:

1. Google Client ID: This identifies your application instance to Google's authentication servers. You can obtain your own by following the steps below.
2. Google Drive Upload Folder Name: This is the name of the folder in your Google Drive where the application will store its index file and any uploaded files/encrypted chunks.

Values entered on the Settings page are stored in your browser's `localStorage` and will override the application's default values.

Follow these steps in the Google Cloud Console:

1. Create or Select a Project.
2. Enable the Google Drive API: Go to "APIs & Services" > "Library", search for "Google Drive API" and enable it.
3. Configure OAuth consent screen:
   • Go to "APIs & Services" > "OAuth consent screen".
   • Choose "External" (or "Internal" for Workspace orgs). Fill in app name, support/developer emails.
   • Scopes: Skip adding scopes here; the application requests them dynamically.
   • Test users: Add your Google account(s), especially if your app status is "Testing". When you publish the app, it can be used by any Google user.
4. Create OAuth 2.0 Client ID:
   • Go to "APIs & Services" > "Credentials". Click "+ CREATE CREDENTIALS" > "OAuth client ID".
   • Application type: "Web application".
   • Name: e.g., "My Cloud File Manager App".
   • "Authorized JavaScript origins": Add your application's hosting URLs (e.g., http://localhost:8000, http://127.0.0.1:8000, https://yourdomain.com). The main.js uses window.location.origin.
   • "Authorized redirect URIs": Add the same URLs. The application uses Google's token client which leverages window.location.origin for its redirect mechanism.
   • Click "CREATE".
5. Copy the Client ID. This is the value you'll enter on the application's Settings page.

The primary way to set these values is through the application's Settings page, accessible from the application's main interface or by navigating to it directly if you know the URL).

• On the Settings page, you will find input fields for "Google Client ID" and "Google Drive Upload Folder Name".
• Values entered here are stored in your browser's `localStorage` and will be used by the application for subsequent sessions.

The application also has default values defined in a file named js/env.js (located in the js/ directory relative to index.html). If you haven't set custom values on the Settings page, or if you reset them using the "Reset Config to Defaults" button on the Settings page, these defaults from js/env.js will be used. For reference, the default Google settings in js/env.js look like this:

You can set two main values via the application's Settings page

1. MSAL Client ID (Application (client) ID): This identifies your application instance to Microsoft's identity platform.
2. OneDrive Fragment Folder Name: The name of the folder in your OneDrive where the application will store encrypted file fragments and the _pwd.json files.

Values entered on the Settings page override the application's defaults.

Follow these steps in the Azure portal:

1. Navigate to Azure Active Directory > "App registrations". Click "+ New registration".
2. Register an application:
   • Name: e.g., "My Cloud File Manager".
   • Supported account types: "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts..." for broad compatibility.
   • Redirect URI: Select "Single-page application (SPA)". Enter your application's hosting URLs (e.g., http://localhost:8000, https://yourdomain.com). The main.js uses window.location.origin as the redirectUri in its MSAL configuration.
   • Click "Register".
3. Copy the Application (client) ID from the app's "Overview" page. This is what you'll enter on the Settings page.
4. API Permissions (Verify/Add if needed):
   • Go to "API permissions" under "Manage".
   • The application requests Files.ReadWrite and User.Read from Microsoft Graph. These are delegated permissions.
     • Click "+ Add a permission" > "Microsoft Graph" > "Delegated permissions".
     • Search for and check: Files.ReadWrite and User.Read.
     • Click "Add permissions".
   • No admin consent is typically required for these permissions for accessing the user's own data.

The primary way to set these values is through the application's Settings page

• On this page, you'll find fields for "MSAL Client ID" and "OneDrive Fragment Folder Name".
• These values are stored in `localStorage` and used by the application.

The application falls back to default values defined in js/env.js if no custom settings are found or if they are reset. For reference, the OneDrive related defaults in js/env.js are:

To open an encrypted preview, the app first downloads the necessary encrypted parts (the main JSON from Google Drive, the fragment from OneDrive, and the password file from OneDrive) and stores them temporarily in your browser's local database (IndexedDB). If the preview page can't find this data, decryption will fail. Here are the most common reasons:

• Private/Incognito Mode: Most browsers block or severely restrict IndexedDB in private browsing or incognito mode. The application cannot cache the required data in this mode. Please use a normal browser window.
• Browser Settings Block Storage: Your browser's privacy settings might be configured to "Block all site data" or block data from third-party contexts, which can interfere with the caching process. Ensure that your browser is allowed to save data for the site where this application is hosted.
• Data Was Cleared: If you manually cleared your browser's cache or site data since the file's components were downloaded, the cached data will be gone. You will need to go back to the main application page and click the 'cache' (🔒) icon for the file again to re-download the components.
• Logout: Using the "Logout" button in the application intentionally clears all local data, including the IndexedDB cache, for security. You will need to re-cache any files you wish to preview after logging back in.
• Corrupted Database (Rare): In very rare cases, the browser's local database could become corrupted. A "hard reset" is the best solution.
  • How to Hard Reset: Open your browser's Developer Tools (usually F12), go to the "Application" tab, find "Storage" in the left-hand menu, and click "Clear site data". This will remove all local storage, indexedDB, and tokens for this site, forcing a fresh start. You will need to sign in to Google/Microsoft again.

• Check Client IDs on Settings Page: First, verify that the Client IDs entered on the application's Settings page exactly match what's provided in the Google Cloud Console and Azure Portal. Typos are common.
• Reset Config to Defaults: If you suspect an issue with your custom settings, try using the "Reset Config to Defaults" button on the Settings page. This will clear your custom values and revert to the application's built-in defaults. Then, try re-entering your custom IDs carefully.
• Authorized Origins/Redirect URIs: Ensure the "Authorized JavaScript origins" and "Authorized redirect URIs" in your Google Cloud OAuth Client ID settings, and the "Redirect URI" for SPA in your Azure App Registration, exactly match the URL you are using to run the application (including the port, e.g., http://localhost:8000). Remember main.js often uses window.location.origin.
• APIs Enabled: Make sure the Google Drive API is enabled in your Google Cloud project. Microsoft Graph permissions should also be correctly set in Azure.
• Browser Console: Open your browser's developer console (usually F12) and look for error messages. These often provide specific clues (e.g., invalid_client, redirect_uri_mismatch).
• Third-Party Cookies: Some browsers with strict third-party cookie blocking might interfere with OAuth flows. Ensure your browser settings allow necessary cookies for accounts.google.com and login.microsoftonline.com or consider adding exceptions if issues persist. Modern libraries often use flows that are less reliant on third-party cookies.
• Clear Application Data: The Settings page also has an option to "Reset Application Data (Keep Config)". This can sometimes help clear out stale session information without losing your Client ID configurations. For a more complete reset, see the "Hard Reset" instructions in the FAQ about encrypted previews.

This application uses robust client-side encryption (AES-GCM-256). Key aspects of its security model:

• File Content Encryption: Your actual file content is encrypted in your browser before any part of it is sent to Google Drive or Microsoft OneDrive.
• Unique Per-File Passwords: Each file is encrypted with its own strong, randomly generated password (File-Specific Password).
• Password Storage: This File-Specific Password is currently stored in a _pwd.json file on your Microsoft OneDrive. While this means an attacker needs access to both your Google Drive (for data) and OneDrive (for the password file) to decrypt a file, we plan to enhance this.
• Distribution: Encrypted data parts and the password file are stored across two different major cloud providers (Google Drive and Microsoft OneDrive).
• Zero Credential Knowledge: The application never knows your Google or Microsoft passwords. It uses OAuth 2.0, where you authenticate directly with Google/Microsoft.
• User-Controlled MFA: Because authentication happens directly with Google/Microsoft, any Multi-Factor Authentication (MFA) you have enabled on those accounts (e.g., authenticator app, security key) will be enforced, adding a strong layer of security to your account access.

Upcoming "Session Master Password" Enhancement:

A future update will significantly improve the security of the File-Specific Passwords. You will be able to set a "Session Master Password" in your browser. This master password will be used to encrypt the File-Specific Password before the _pwd.json file is saved to OneDrive. This means that even if an attacker gains access to both your Google Drive and OneDrive accounts, they *still* wouldn't be able to decrypt your files without also knowing your Session Master Password.

Current Security Relies on:

• The secrecy of your Google and Microsoft account credentials (protected by your passwords and any MFA you've enabled).
• The security of your own computer and browser environment.
• Using your own, private Client IDs obtained from Google and Microsoft, as configured on the Settings page.

No system is 100% unbreachable, but the multi-provider approach and client-side encryption offer a strong defense. The upcoming Session Master Password feature will elevate this further.