Hacker Newsnew | past | comments | ask | show | jobs | submit | _rlx_'s commentslogin

> Without fingerprinting/certification of the entire javascript-source the server > could serve a manipulated source code that exfiltrates data

This is actually one of the described use cases of the new webpackage specification: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas...

Here is the current draft: https://wicg.github.io/webpackage/draft-yasskin-dispatch-web...


This is what the webext-signed-pages [1] extension does. This only works in a secure manner with Firefox though because Chrome extensions don't have access to the content of the HTTP responses [2].

[1] https://github.com/tasn/webext-signed-pages [2] https://bugs.chromium.org/p/chromium/issues/detail?id=487422


https://docs.tanker.io/latest/guide/device-unlocking/#end-to...

> If you want your app to be fully end-to-end, you can use the lower level > unlock mechanisms, which are all end-to-end compliant

So if I want to use the SDK in a "fully" end-to-end secure way, I first need to implement by myself a secure way to transmit the user root secret (the unlock key) between the user's devices, and make sure this key is always accessible so that users don't loose access to their data. This doesn't seem like an easy task...


No, the unlock key is for the user to keep, and never be transmitted by anyone else than the user themselves. If you do the transmission, it's not end to end anymore.

This option is only for users concerned about security, the other unlock methods are less strong but still provide security.


This is a current Firefox restriction: https://bugzilla.mozilla.org/show_bug.cgi?id=1413615


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: