There are several options: 1. capture file:// and ignore it in the short-term, add confinement and content-hub later 2. add confinement and content-hub now 3. add content-hub now and confinement later 4. add confinement now and content-hub later 5. do nothing
'5' is probably out of the question at this point, since it is the status quo and it is clear no one is happy with it. :) '1' is an option as a band-aid, but it requires development work. It isn't clear to me that capturing file contributes to using content-hub later. This is possibly a short term fix. '2' fixes everything all at once. This would require talking work away from other areas and needs design input. This is a medium term fix. '3' is similar to '1', but makes sure we are in alignment for future engineering work. This is a medium term fix. '4' has a similar affect to '1' in that it breaks file:// access, but also covers any other access. It can be a short term fix and aligns with future engineering work. I believe '4' (this is bug #1356516) is the path forward in the short term. It addresses the security and privacy concerns and aligns with future engineering work. For convergence, content-hub integration will be a requirement. I'll discuss this with the oxide team and report back. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1393515 Title: browser allows browsing the phone filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1393515/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
