I agree, privacy and security would definitely be a huge concern! I wonder if we'll have to set up a trust server or service or a whitelisting server? Can we do that in a P2P method within the local network?
I could foresee NFC being used to redirect a device to another device. The main issue is hijacking and such. How do you prevent unwanted connection... Do you have to whitelist the NFC with certain devices? Mac IP? Would fly web server have to be adjusted to also know who to trust? On Sun, Dec 27, 2015 at 7:11 PM, Paul Theriault <ptheria...@mozilla.com> wrote: > This is an extremely important discussion! We’ve actually been struggling > with this exact issue for the remote control on the TV. TLS doesn’t suit > because the TV has an internal network address only (no public DNS name). > We’ve been discussing how to implement the trust relationship between the > remote control web page running on an arbitrary device/browser and the TV. > I’m not sure that this is a good solution (I’m all ears if anyone has a > suggestion) > > Some (not very well structured) thoughts on your questions in line below. > > On 24 Dec 2015, at 12:31 am, Michiel de Jong <mbdej...@mozilla.com> wrote: > > Connecting from a web browser to a web site is just a special case of > using "Device A", to connect to "Device B". Looking at the generic case > where Device A and Device B can both be anyThing ;) brings up a few > interesting questions: > > 1) How can a certificate authority vouch for the identity of Device B, if > it does not have a URL? Unless we replace CA's with Web-of-Trust, this > might be something to think about as more devices come into play that have > no URL. > > > Even with a URL, on an internal network CAs are of limited use (works for > enterprise when you can pre-install a CA, but not in the general case). But > how this “web-of-trust’ would work, I’m not sure. Exchange of CA via some > side-channel? Or maybe exchange WebRTC SDP and then you can use > dataConnection to securely communicate - but that doesn’t doesn’t solve the > problem of secure code delivery in the first place. Another option might be > to leverage an external trusted source to broker the initial communication > (https://trustedapp.marketplace.firefox.com) but then both devices need > access to the internet. > > > 2) The user might have Device B in their eye sight. Does that help? > > > If Device B can be many more things than just a web server in a data > center, then you may be able to connect to it with more accuracy. For > instance, by sticking a USB cable in it, touching it with your NFC reader, > or pointing a camera at it. > > > Definitely! There is much prior art for local-area identification and > authentication. Of the top of my head (and a quick search on the web) I can > think of: > - exchange of pin codes (e.g. bluetooth pairing) > - physical proximity (NFC, or use physical sensors, e.g. bluetooth signal > strength, or physical “bumps”) > - Visual data encoding (e.g QR codes, or > https://www.youtube.com/watch?v=sVWlQNzU4Ak ) > - (Ultra)Sonic data encoding ( e.g. > https://github.com/borismus/sonicnet.js) > > It might be interesting to consider a standard approach for exchanging > authentication information (i’d be surprised if there wasn’t any standards > in this space actually) > > 3) How can you accurately connect to a device if you have no URL, and also > no physical proximity? > > I'm not talking about how to protect Device B from unauthorized access > (WPS buttons on WiFi routers etc.). What interests me is how you as a user > can accurately identify the device you are connecting *to*. > > > I don’t think you can, at least automatically unless there is some prior > web-of-trust. It depends what you mean by ‘no physical proximity’ too. Do > you mean too far to use a side-channel like bluetooth, but still on the > same LAN. Or something else? Are we even talking TCP/IP here or something > completely seperate? > > > Curious if anyone has more thoughts on this! :) > > > Me too! Im afraid I’ve not seen any good solutions in this space as yet > but I’ve only just started digging. > > > > > Cheers, > Michiel. > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos > > > > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
