4 ms·

Passwords, medical records and credit card information are so sensitive that it's irrelevant that there are good uses for the tech that captures them or that at

Passwords, medical records and credit card information are so sensitive that it's irrelevant that there are good uses for the tech that captures them or that at some point in the pipeline they get masked.

mattzito 9y ago
So, to be clear, the way at least the tools I've worked with operate: - websites implementing these tools need to specifically opt-in text fields they want to capture the inputs for - for HTML-side capture, the javascript will obfuscate PII before sending it to the servers - some of these tools will not capture password fields under any circumstances Does that address some of your concerns?
- Brotkrumen 9y ago
  No. There's too many parties involved I'd have to trust to a) want to keep my data save and b) don't mess up. And even if both are true, I have to accept yet another way with several points of failure where bad agent could exfiltrate my data.
  - PJDK 9y ago
    But this is being run by a party you trust with that data in the first place surely? It's capturing the things you are typing into the website's input boxes!
    - krangu 9y ago
      Just because you trust the first party site with that information doesn't mean you would necessarily trust a third party to store or transmit that info.
    - orwin 9y ago
      We trust the website we give our information to. It is https-based (else my browser will tell me) and probably using an ORM that will 99% of the time hash my password. But the javascript layer... Sorry, call me paranoiac, but i will never trust the javascript of a website. With no webdev experience, i was able to inject js (almost by mistake) three years ago. Moreover, is the js communicating with the backend using https too? How can i check that? Are those js library on the website server, or are they hosted by a third party? I can trust them, but how do i know that no attacker was able to modify those scripts? Yes, those risks are small, but i'd rather have ublock making those risks closer tho 0 than not, am i wrong?

mattzito 9y ago

So, to be clear, the way at least the tools I've worked with operate: - websites implementing these tools need to specifically opt-in text fields they want to capture the inputs for - for HTML-side capture, the javascript will obfuscate PII before sending it to the servers - some of these tools will not capture password fields under any circumstances Does that address some of your concerns?

Brotkrumen 9y ago
No. There's too many parties involved I'd have to trust to a) want to keep my data save and b) don't mess up. And even if both are true, I have to accept yet another way with several points of failure where bad agent could exfiltrate my data.
- PJDK 9y ago
  But this is being run by a party you trust with that data in the first place surely? It's capturing the things you are typing into the website's input boxes!
  - krangu 9y ago
    Just because you trust the first party site with that information doesn't mean you would necessarily trust a third party to store or transmit that info.
  - orwin 9y ago
    We trust the website we give our information to. It is https-based (else my browser will tell me) and probably using an ORM that will 99% of the time hash my password. But the javascript layer... Sorry, call me paranoiac, but i will never trust the javascript of a website. With no webdev experience, i was able to inject js (almost by mistake) three years ago. Moreover, is the js communicating with the backend using https too? How can i check that? Are those js library on the website server, or are they hosted by a third party? I can trust them, but how do i know that no attacker was able to modify those scripts? Yes, those risks are small, but i'd rather have ublock making those risks closer tho 0 than not, am i wrong?