4 ms·

Privacy concern is the main reason we still have a local-only mode in our transcription app [1]. It’s a web-app, but we play the audio/video file directly from

by jabo 6y ago

Privacy concern is the main reason we still have a local-only mode in our transcription app [1]. It’s a web-app, but we play the audio/video file directly from the user’s computer, and we use local storage to store typed text in users’ browsers. This way no transcription data leaves users’ computers. We also use service workers to allow this mode to work offline, for good measure. We’ve been working on it for over a decade and we did add machine transcription recently, but I still find a surprising number of users use and ask about the local-only “Self Transcription” mode. One interesting side-effect of a local-only mode is that we can’t sync transcript data between computers. And this sometimes surprises people. Once we explain that this is actually a feature not a bug, since we don’t store the data on our servers to be able to do the sync, it actually seems to reassure people even more. [1] https://transcribe.wreally.com https://transcribe.wreally.com

lupire 6y ago
A post on HN yesterday said Local Storage is not secure from XSS attacks.
- jabo 6y ago
  Thanks for sharing. Just read through it and like one of the comments mentioned, if malicious JS is able to run on any site, that’s a larger issue and would affect not just local storage right?
  - UweSchmidt 6y ago
    Someone would have to make specific JS to target your specific app/service and specific users, as well as in some way "launder" the stolen data. Totally different 'order of magnitude' from automatically and legally taking the users' data. I hope this is the correct way to evaluate these kind of things?
- gruez 6y ago
  And that's fine right? If it was a desktop app instead, you could say that it's not secure against sandbox escapes and stack smashing attacks. It's still a step-up in security compared to cloud transcription services, and for most use cases perfectly adequate.
Jon_Lowtek 6y ago
This "privacy concerned" app has a myriad of analytics and tracking scripts which can read the transcript in local storage or log key presses (but are hopefully not be configured that way). Typical privacy friendly defaults like google analytics anonymize_ip are not set. There are no checks for the integrity of these third party scripts (a hack against them can lead to a breach of the app) and it does not ask for consent before connecting the user to these third party servers. There is also an error logging service (datadog) and i have seen other apps push all state info, including local storage and auth tokens, when any error happens. The promise of the recording and transcript not leaving the users computer in local-only mode may be true, if its implemented correctly. The privacy policy looks halfway decent, a bit chaotic with no ToC and free-floating "legal basis" & "retention policy" that are independent from the concrete processing tasks, leaving them as abstract "we know the law" blocks of little value. The policy is very dominated by all the user behavior tracking and ad-tech integrations, while the processing of recordings/transcriptions is rather short. In a way that is good, but it is almost too short, given that it is the primary function: "transcripts" and "recordings" are not even a category of data in their policy, and they are not mentioned with any sub-processor, not even by the ones running the servers (a rather curious formal error, as one would assume a focus on their core business). There is a complete lack of "we keep small samples to improve the ML/AI" which i find inteersting, but which might be true. There is a small note in the legal texts that the user must have the consent of the recorded people before uploading recordings to the server for automatic transcriptions, but there does not seem to be one in proximity to the upload function. (or at least they are missing from the screenshots in the guides, i did not register for a trial)

by jabo 6y ago

lupire 6y ago

A post on HN yesterday said Local Storage is not secure from XSS attacks.

jabo 6y ago
Thanks for sharing. Just read through it and like one of the comments mentioned, if malicious JS is able to run on any site, that’s a larger issue and would affect not just local storage right?
- UweSchmidt 6y ago
  Someone would have to make specific JS to target your specific app/service and specific users, as well as in some way "launder" the stolen data. Totally different 'order of magnitude' from automatically and legally taking the users' data. I hope this is the correct way to evaluate these kind of things?
gruez 6y ago
And that's fine right? If it was a desktop app instead, you could say that it's not secure against sandbox escapes and stack smashing attacks. It's still a step-up in security compared to cloud transcription services, and for most use cases perfectly adequate.

Jon_Lowtek 6y ago

This "privacy concerned" app has a myriad of analytics and tracking scripts which can read the transcript in local storage or log key presses (but are hopefully not be configured that way). Typical privacy friendly defaults like google analytics anonymize_ip are not set. There are no checks for the integrity of these third party scripts (a hack against them can lead to a breach of the app) and it does not ask for consent before connecting the user to these third party servers. There is also an error logging service (datadog) and i have seen other apps push all state info, including local storage and auth tokens, when any error happens. The promise of the recording and transcript not leaving the users computer in local-only mode may be true, if its implemented correctly. The privacy policy looks halfway decent, a bit chaotic with no ToC and free-floating "legal basis" & "retention policy" that are independent from the concrete processing tasks, leaving them as abstract "we know the law" blocks of little value. The policy is very dominated by all the user behavior tracking and ad-tech integrations, while the processing of recordings/transcriptions is rather short. In a way that is good, but it is almost too short, given that it is the primary function: "transcripts" and "recordings" are not even a category of data in their policy, and they are not mentioned with any sub-processor, not even by the ones running the servers (a rather curious formal error, as one would assume a focus on their core business). There is a complete lack of "we keep small samples to improve the ML/AI" which i find inteersting, but which might be true. There is a small note in the legal texts that the user must have the consent of the recorded people before uploading recordings to the server for automatic transcriptions, but there does not seem to be one in proximity to the upload function. (or at least they are missing from the screenshots in the guides, i did not register for a trial)