5 ms·

it's a text editor. Users expect to edit files in any random directory they'll make on drive, not in the containment scope that doesn't work with users' writing

by SSLy 2y ago

it's a text editor. Users expect to edit files in any random directory they'll make on drive, not in the containment scope that doesn't work with users' writing habits.

0cf8612b2e1e 2y ago
From the description, the app launches an OS controlled file picker. Once the human picks a file, the app is given a file handle with read/write permissions. Any file is fair game to be used within the app, but the application does not get to know anything about the file system.
- layer8 2y ago
  This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file from the Files app. This would also mean that the app can’t maintain a “recent files” list (or bookmarks) for the user to be able to quickly reopen a previously opened file, because that wouldn’t be going through the file picker.
  - tadfisher 2y ago
    That is not true; you can hang on to the content URI and metadata to present a Recent Files UI. You need to ask for a persisted write permission for the content URI. You can even use the ContentResolver to check the file's existence and update the metadata (including thumbnail).
    - iggldiggl 2y ago
      Although AFAIK Android's implementation then means that you can end up with duplicate entries for the same file if you open it through differing means (like both through an external file manager as well as within the app's own UI), because those result in distinct content URIs and there are no official APIs that would allow you to confirm whether two separate content URIs are actually pointing to the same file (where that'd make sense, e.g. for files on the local file system at least [1]). [1] I think there are some hacks to work around that issue, but obviously they aren't guaranteed to work all of the time.
ajross 2y ago
To be blunt: how do you know it's not an exfiltration app that will suck down your entire Drive and upload it to their sponsor's ML training engine? Text editors are great, but hand-installed editors[1] running on the local filesystem of a developer-maintained personal device are a very different threat model than an app available to everyone in the Play Store. [1] And even then they tend strongly to be boosted by a large community of (usually) open source developers attesting to it, usually by inclusion in something like a "Linux Distro" which carries a strong promise of well-audited software. Emacs and VSCode and whatnot skate on reputation, basically, but the community tends to frown on "here: download my new binary tool for all your editting needs!".
- fragmede 2y ago
  I like how ML training is the worst thing you can think of and not stealing your identity and bank account information and all your money or seeing nudes or something actually damaging that normal people care about.
  - ajross 2y ago
    I was trying to be trendy and hip and avoid hyperbole. But yeah, that too. Also boring stuff like corporate espionage and malware distribution.
  - cudgy 2y ago
    Are you assuming that the ML company does not sell its training data to scammers or others that will sell to scammers?
    - fragmede 2y ago
      Yes, I am assuming that AI won’t sell the text of my chats to scammers just like I assume Google won’t sell my Google search history to anybody that wants to personally hurt me. I distinguish between an ad company wanting to make money showing me ads and an individual calling my parents trying to get them to send the scammer money saying that I’m the hospital so cash app them $600 please.
hn_throwaway_99 2y ago
I wouldn't want any text editor app to have full rights to my Google Drive. I literally recently implemented a similar feature (not for a text editor but for an app that needed to pull files from many different sources), and it's not that hard, i.e. giving easy access to local files and then using the picker control for "Drive imports". The problem here is the original app developer had full, willy-nilly Drive access, and when Google rightfully locked down this level of access (and, mind you, didn't prohibit - I've gone through the Drive restricted scope verification process and it's not as hard as this blog post is making it out to be), the developer didn't take the time to see what was necessary to comply. Again, I have no doubt Google could have given better instructions on how to migrate to the drive.file scope or how to use the restricted scopes. But Google has been warning about this for many years now, so seems like this dev just scrambled at the last minute.
- stickfigure 2y ago
  > I wouldn't want any text editor app to have full rights to my Google Drive. What text editor do you use on your laptop/desktop/pc?
  - hn_throwaway_99 2y ago
    Primarily vim or VSCode, why?
    - klabb3 2y ago
      Parent means that your desktop OS is not sandboxed and your editor has permissions to read any file you have access to, including mounted Cloud Drives, as well as showing a custom file explorer (which both Vim and VSCode do, btw) and does not require special scoping on a file-by-file basis to happen in some OS controlled, confusing back-and-forth dance. The security model on mobile, despite being gate kept and sandboxed to an extreme, still has massive giant glaring problems with malware, phishing and tracking (although that’s more of a feature). To double down on this strategy, by whitelisting, reviewing, authorizing, auditing, and blessing entitlements in holy corporate water – shows an amusing incongruence in contrast with say Linux which by almost every metric is more secure despite none of that, and to a lesser extent, macOS and Windows.

by SSLy 2y ago

it's a text editor. Users expect to edit files in any random directory they'll make on drive, not in the containment scope that doesn't work with users' writing habits.

0cf8612b2e1e 2y ago

From the description, the app launches an OS controlled file picker. Once the human picks a file, the app is given a file handle with read/write permissions. Any file is fair game to be used within the app, but the application does not get to know anything about the file system.

layer8 2y ago
This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file from the Files app. This would also mean that the app can’t maintain a “recent files” list (or bookmarks) for the user to be able to quickly reopen a previously opened file, because that wouldn’t be going through the file picker.
- tadfisher 2y ago
  That is not true; you can hang on to the content URI and metadata to present a Recent Files UI. You need to ask for a persisted write permission for the content URI. You can even use the ContentResolver to check the file's existence and update the metadata (including thumbnail).
  - iggldiggl 2y ago
    Although AFAIK Android's implementation then means that you can end up with duplicate entries for the same file if you open it through differing means (like both through an external file manager as well as within the app's own UI), because those result in distinct content URIs and there are no official APIs that would allow you to confirm whether two separate content URIs are actually pointing to the same file (where that'd make sense, e.g. for files on the local file system at least [1]). [1] I think there are some hacks to work around that issue, but obviously they aren't guaranteed to work all of the time.

ajross 2y ago

To be blunt: how do you know it's not an exfiltration app that will suck down your entire Drive and upload it to their sponsor's ML training engine? Text editors are great, but hand-installed editors[1] running on the local filesystem of a developer-maintained personal device are a very different threat model than an app available to everyone in the Play Store. [1] And even then they tend strongly to be boosted by a large community of (usually) open source developers attesting to it, usually by inclusion in something like a "Linux Distro" which carries a strong promise of well-audited software. Emacs and VSCode and whatnot skate on reputation, basically, but the community tends to frown on "here: download my new binary tool for all your editting needs!".

fragmede 2y ago
I like how ML training is the worst thing you can think of and not stealing your identity and bank account information and all your money or seeing nudes or something actually damaging that normal people care about.
- ajross 2y ago
  I was trying to be trendy and hip and avoid hyperbole. But yeah, that too. Also boring stuff like corporate espionage and malware distribution.
- cudgy 2y ago
  Are you assuming that the ML company does not sell its training data to scammers or others that will sell to scammers?
  - fragmede 2y ago
    Yes, I am assuming that AI won’t sell the text of my chats to scammers just like I assume Google won’t sell my Google search history to anybody that wants to personally hurt me. I distinguish between an ad company wanting to make money showing me ads and an individual calling my parents trying to get them to send the scammer money saying that I’m the hospital so cash app them $600 please.

hn_throwaway_99 2y ago

I wouldn't want any text editor app to have full rights to my Google Drive. I literally recently implemented a similar feature (not for a text editor but for an app that needed to pull files from many different sources), and it's not that hard, i.e. giving easy access to local files and then using the picker control for "Drive imports". The problem here is the original app developer had full, willy-nilly Drive access, and when Google rightfully locked down this level of access (and, mind you, didn't prohibit - I've gone through the Drive restricted scope verification process and it's not as hard as this blog post is making it out to be), the developer didn't take the time to see what was necessary to comply. Again, I have no doubt Google could have given better instructions on how to migrate to the drive.file scope or how to use the restricted scopes. But Google has been warning about this for many years now, so seems like this dev just scrambled at the last minute.

stickfigure 2y ago
> I wouldn't want any text editor app to have full rights to my Google Drive. What text editor do you use on your laptop/desktop/pc?
- hn_throwaway_99 2y ago
  Primarily vim or VSCode, why?
  - klabb3 2y ago
    Parent means that your desktop OS is not sandboxed and your editor has permissions to read any file you have access to, including mounted Cloud Drives, as well as showing a custom file explorer (which both Vim and VSCode do, btw) and does not require special scoping on a file-by-file basis to happen in some OS controlled, confusing back-and-forth dance. The security model on mobile, despite being gate kept and sandboxed to an extreme, still has massive giant glaring problems with malware, phishing and tracking (although that’s more of a feature). To double down on this strategy, by whitelisting, reviewing, authorizing, auditing, and blessing entitlements in holy corporate water – shows an amusing incongruence in contrast with say Linux which by almost every metric is more secure despite none of that, and to a lesser extent, macOS and Windows.