Re: FileSystemWritableFileStream What is the compelling technical reason for creating and writing to .crswap files instead of the actual file?
115 views
Skip to first unread message
guest271314
Feb 16, 2025, 8:23:38 PMFeb 16
to Chromium-dev
No developer want to create .crswap files.
I can't think of any compelling reason why the .crswap file is created and written to, then moved to the actual file.
Creating .crswap files at least doubles the computational resources needed to write local files with FileSystemWritableFileStream. Temporary file is created. Then temporary file is moved to actual file.
In the process orphan .crswap files can be created. Granted, those .crswap files get deleted when the document reloads, like a Blob URL. Though I can't see any technical benefit for creating the .crswap file in the first place, instead of just creating the actual file.
With no reason for doing so.
What is the compelling technical reason for creating and writing to .crswap files instead of the actual file?
Reilly Grant
Feb 18, 2025, 6:33:28 PMFeb 18
to guest...@gmail.com, Chromium-dev
As discussed in the issues you linked to, the reason for using a .crswap file is to give local security scanning software the opportunity to examine the modified file before the changes are committed to a file that may be interpreted by other applications on the system. For example, a malicious site could try to exploit an issue in the system's JPEG parser for thumbnail image creation. If the new file contents were written directly to a .jpg file they might be immediately interpreted by the system, triggering the exploit. By writing to the .crswap file first and then asking the system to run security scans (e.g. Windows Defender) before the contents are moved to the .jpg file this exploit is mitigated.
On platforms and filesystems where this is possible renaming the .crswap file does not require copying any of the contents. In addition on file systems which expose copy-on-write semantics (so far we only use this on macOS to my knowledge) the creation of the .crswap file from the original file contents is also done without copying any bytes.
If the application needs the performance of direct file writes it can use the Origin Private File System which mitigates the concern above by storing files in a site-specific storage area which is not accessed by other applications on the system.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/10cee601-fdbd-4ef2-8af1-0919bae52020n%40chromium.org.
PhistucK
Feb 18, 2025, 11:45:05 PMFeb 18
to rei...@chromium.org, guest...@gmail.com, Chromium-dev
> If the application needs the performance of direct file writes it can use the Origin Private File System which mitigates the concern above by storing files in a site-specific storage area which is not accessed by other applications on the system.
Not really helpful if the file is supposed to be available to the user. For example, transferring files between machines. If they are huge/multiple-GB files and the transfer is resumable and this is done in chunks, this can generate a huge amount of redundant disk activity, deteriorating the disk as well, especially SSDs.
Not really helpful if the file is supposed to be available to the user. For example, transferring files between machines. If they are huge/multiple-GB files and the transfer is resumable and this is done in chunks, this can generate a huge amount of redundant disk activity, deteriorating the disk as well, especially SSDs.
Maybe add a permission for this kind of thing? It is just wasteful, at least on Windows, as well as time consuming (waiting until the file is settled).
:(
☆PhistucK
guest271314
Feb 19, 2025, 2:06:07 AMFeb 19
to Reilly Grant, Chromium-dev
,> As discussed in the issues you linked to, the reason for using a
the following reasons:
1. If a user is committed to scanning files they can scan the actual
file being written. Writing a .crswap file first doesn't change
anything relevant to scanning files.
> For example, a malicious site could try to exploit an issue in the system's JPEG parser for thumbnail image creation.
2. Nothing is stopping the same exploit from happening when the
.crswap file is written.
> By writing to the .crswap file first and then asking the system to run security scans (e.g. Windows Defender) before the contents are moved to the .jpg file this exploit is mitigated.
3. Nothing is stopping the system from scanning the actual file Or
scanning the .crswap file. Nothing is gained by writing to a .crswap
file first.
> On platforms and filesystems where this is possible renaming the .crswap file does not require copying any of the contents.
4. Not following. Just write the actual file instead of those
Chromium-specific .crswap files.
> If the application needs the performance of direct file writes it can use the Origin Private File System which mitigates the concern above by storing files in a site-specific storage area which is not accessed by other applications on the system.
5. That's simply technically untrue. Here's how to get the files and
directories from "Origin Private File System", which is just writing
to the "File System" folder in Chromium/Chrome configuration folder
https://gist.github.com/guest271314/78372b8f3fabb1ecf95d492a028d10dd#file-createreadwritedirectoriesinbrowser-js-L118-L162
// Helper function for filesystem *development*
// Get directory in origin private file system from Chrome configuration folder.
// fetch() file: protocol with "file://*/*" or "<all_urls>" in
"host_permissions"
// in browser extension manifest.json
async function parseChromeDefaultFileSystem(path) {
try {
const set = new Set([
32, 45, 46, 47, 48, 49, 50, 51, 52, 53,
54, 55, 56, 57, 58, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
89, 90, 95, 97, 98, 99, 100, 101, 102,
103, 104, 105, 106, 107, 108, 109, 110,
111, 112, 113, 114, 115, 116, 117, 118,
119, 120, 121, 122,
]);
const request = await fetch(path);
const text = (await request.text()).replace(/./g, (s) =>
set.has(s.codePointAt()) ? s : "");
const files = [
...new Set(
text.match(
/00000\d+[A-Za-z-_.0-9\s]+\.crswap/g,
),
),
].map((s) => {
const dir = [...new Set(text.slice(0,
text.indexOf(s)).match(/(?<=[@\s]|CHILD_OF:0:)([\w-_])+(?=Ux)/g).map((d)
=>
d.split(/\d+|D140/)
))].flat().pop();
const re = /00000[\d\s]+|\.crswap/g;
const [key] = s.match(re);
return ({
[key]: s.replace(re, ""),
dir
})
});
return {
name: files[0].dir,
files
}
} catch (e) {
console.error(e);
}
}
// let paths = await
parseChromeDefaultFileSystem("file:///home/user/.config/chromium/Default/File\
System/021/t/Paths/000003.log");
// console.log(JSON.stringify(paths, null, 2));
6. Lastly. I'm a programmer and a user. If I decide to not scan files
I download from the Web that should be my choice. Just like if I don't
want Google Search to be my default search engine. Simply provide a
flag for users on their own machine to get rid of writing that useless
.crswap file.
.crswap file is to give local security scanning software the
opportunity to examine the modified file before the changes are
committed to a file that may be interpreted by other applications on
the system.
The proferred reasoning in the linked issues makes no sense to me. For
opportunity to examine the modified file before the changes are
committed to a file that may be interpreted by other applications on
the system.
the following reasons:
1. If a user is committed to scanning files they can scan the actual
file being written. Writing a .crswap file first doesn't change
anything relevant to scanning files.
> For example, a malicious site could try to exploit an issue in the system's JPEG parser for thumbnail image creation.
.crswap file is written.
> By writing to the .crswap file first and then asking the system to run security scans (e.g. Windows Defender) before the contents are moved to the .jpg file this exploit is mitigated.
scanning the .crswap file. Nothing is gained by writing to a .crswap
file first.
> On platforms and filesystems where this is possible renaming the .crswap file does not require copying any of the contents.
Chromium-specific .crswap files.
> If the application needs the performance of direct file writes it can use the Origin Private File System which mitigates the concern above by storing files in a site-specific storage area which is not accessed by other applications on the system.
directories from "Origin Private File System", which is just writing
to the "File System" folder in Chromium/Chrome configuration folder
https://gist.github.com/guest271314/78372b8f3fabb1ecf95d492a028d10dd#file-createreadwritedirectoriesinbrowser-js-L118-L162
// Helper function for filesystem *development*
// Get directory in origin private file system from Chrome configuration folder.
// fetch() file: protocol with "file://*/*" or "<all_urls>" in
"host_permissions"
// in browser extension manifest.json
async function parseChromeDefaultFileSystem(path) {
try {
const set = new Set([
32, 45, 46, 47, 48, 49, 50, 51, 52, 53,
54, 55, 56, 57, 58, 64, 65, 66, 67, 68,
69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
79, 80, 81, 82, 83, 84, 85, 86, 87, 88,
89, 90, 95, 97, 98, 99, 100, 101, 102,
103, 104, 105, 106, 107, 108, 109, 110,
111, 112, 113, 114, 115, 116, 117, 118,
119, 120, 121, 122,
]);
const request = await fetch(path);
const text = (await request.text()).replace(/./g, (s) =>
set.has(s.codePointAt()) ? s : "");
const files = [
...new Set(
text.match(
/00000\d+[A-Za-z-_.0-9\s]+\.crswap/g,
),
),
].map((s) => {
const dir = [...new Set(text.slice(0,
text.indexOf(s)).match(/(?<=[@\s]|CHILD_OF:0:)([\w-_])+(?=Ux)/g).map((d)
=>
d.split(/\d+|D140/)
))].flat().pop();
const re = /00000[\d\s]+|\.crswap/g;
const [key] = s.match(re);
return ({
[key]: s.replace(re, ""),
dir
})
});
return {
name: files[0].dir,
files
}
} catch (e) {
console.error(e);
}
}
// let paths = await
parseChromeDefaultFileSystem("file:///home/user/.config/chromium/Default/File\
System/021/t/Paths/000003.log");
// console.log(JSON.stringify(paths, null, 2));
6. Lastly. I'm a programmer and a user. If I decide to not scan files
I download from the Web that should be my choice. Just like if I don't
want Google Search to be my default search engine. Simply provide a
flag for users on their own machine to get rid of writing that useless
.crswap file.
guest271314
Feb 19, 2025, 2:26:44 AMFeb 19
to Chromium-dev, guest271314, Chromium-dev, Reilly Grant
> Not really helpful if the file is supposed to be available to the user. For example, transferring files between machines. If they are huge/multiple-GB files and the transfer is resumable and this is done in chunks, this can generate a huge amount of redundant disk activity, deteriorating the disk as well, especially SSDs.
>
> Maybe add a permission for this kind of thing? It is just wasteful, at least on Windows, as well as time consuming (waiting until the file is settled).
>
> :(
Right. Pretty simple.
I'm on Linux. Every couple of days I fetch Chromium Devloper Build. One of the first things I do is turn off Google Safe Browsing and set my own new tab page and my own default search engine - which is an extension that doesn't actually search for anything because I don;t want to automatically search for something just because I type in the Omnibox.
Another thing I do immediately is delete the "Safe Browsing" and "screen_ai" folders in the Chromium configuration folder. I have no use for either.
A while ago a maintainer of File System Access API - formerly Native File System said something like the Google "security" folks insisted on scanning files.
Now, since I deliberately turn off Google Safe Browsing there should be no "scanning" taking place at all.
The rationale that writing to a temporary .crswap file first is somehow a "security" measure doesn't add up. It's the same content. Unless Google is somehow reading users' data even though they have Google Safe Browsing turned off?!
Over and over again developers in the field have stated clearly the expense of writing .crswap files then moving that .crswap file to the actual file.
That expense doesn't just magically go away. Unless Chromium has figured out a way to move files atomically - which doesn't happen in practice as evinced by the standing issues re creation of those .crswap files.
WHATWG File System Standard really has nothing to do with WICG File System Access API. Two different API's.
And as demonstrated above, that data is not really secluded off in some incaccessible domain. Any program can read the Chromium configuration folder and get the directories and files written to "File System" folder; whether that be data written using the old File System API's, or new file system API's.
Moreover, this should be *user choice*, not a corporate or maintainer choice as to what constitutes "security" and what files and folders the user decides to download to their machine. It's the users' machine!
There's no reason why an API option and/or flag can't be defined.
I mean, Google is baking "AI" into the browser - by user choice. Nothing should be considered outside the scope of the user defined capabilities given Google is shipping "screen_ai" in the browser without any user asking for that feature explicitly.
Message has been deleted
guest271314
Feb 20, 2025, 3:30:26 PMFeb 20
to Chromium-dev, guest271314, Chromium-dev, Reilly Grant
In the Settings UI there are these *options* . I'm pretty sure the Web won't break with the user provided the option to allow specific sites direct file write access *without* creating that .crswap file. 
I notice that libchromescreenai.so is 96 MB! And it's not a .crswap file! So Google has unilaterally decided that screen_ai is not malicious, and not given the user the ability to not have that ~100MB file on the machine!
The option both in UI and using commandline switches and/or policy can be provided to the user - without impacting somebody on Windows using Windows Defender doing whatever they do with .crswap files.
I notice that libchromescreenai.so is 96 MB! And it's not a .crswap file! So Google has unilaterally decided that screen_ai is not malicious, and not given the user the ability to not have that ~100MB file on the machine!
The option both in UI and using commandline switches and/or policy can be provided to the user - without impacting somebody on Windows using Windows Defender doing whatever they do with .crswap files.
Reply all
Reply to author
Forward
0 new messages