What are the standards or protocols for communicating smart home elements? If I release my smart light bulb, what standards should I follow in order for it to work with Google Home, Xiaomi Mi Home, Amazon Alexa, etc.?
If you want to integrate with the Google Assistant, you will need a way for the lightbulb communicate through the Internet. This could be through a direct Wi-Fi service or an Internet connected hub. Execution can be done over a local network, but still requires access to the Internet to respond to other intents.
I do not know the requirements of the other systems.
There are some news reports about the international smart home standard from The Open Connectivity Foundation (OCF).
https://www.helpnetsecurity.com/2020/01/06/smart-home-standard/
Related
I am looking to implement DRM on my learning management system React app to block unauthorized content downloads. Using VPS as web hosting as well as content hosting. The VPS is running on Ubuntu 20.04.
I am guessing you are talking about video content.
Assuming this is the case you need to either use a video hosting service which has a DRM service included, such as Vimeo, Brightcove etc, or else host and stream the video yourself, perhaps using a streaming solution - see below, and add the DRM when you stream.
For the latter you will need a service from one or all of the main DRM providers deepening on what platforms you want to cover (very high level - Widevine for Google browsers and devices, FairPlay for Apple and PlayReady for Microsoft but some exceptions and caveats) or else with a multiDRM provider who will interface with the DRM provider for you.
If you just want a simple and cheaper protection you may find a combination of authentication, secure URLs and very basic Clear Key encryption may be enough for you, but again the complexity to stream efficiently can be large so it may be worth looking at existing streaming server solutions like Wowza, AWS Media Services, Azure Media Services etc.
As a personal hobby, I would like to program a web-based card game with a few tokens and write an AI for it. I do not want to spend time and effort on standard elements such as maintaining a list of games and coordinating who's playing who, or even writing a login system (ideally I'd like to use Google accounts).
My choice of programming language is flexible, but would prefer something I could run on Google app engine.
I know Google Play Games provides some of the APIs but I was hoping for something more comprehensive. Even better if it works with Google Play Games.
Can you recommend toolkits that provide all or most of this functionality?
Board Game Arena supplies the community and lobby for your online board game, and also provides hosting and the community of players, and helps deal with licensing. The big downside is that you must comply with their system, and must write in PHP, and they don't work with Google accounts.
That said, it is a solution for the problem presented in the question, at least in some cases.
Though I am sure this is a little less fully formed than you were hoping, I would propose WT Toolkit, which allows for javascript-less C++ web applications.
Does it support a login system? Yes it does! supporting both google and facebook, with an easy path to integrationg other OAuth methods (hotmail for example)
List of games? std::vector
List of current people playing others? std::unordered_map
Games are closer to native apps than they are to web pages; a framework that allows you to leverage typical game design methods and exposed WebGL through a unified interface, like WT does, might make it easier for you by allowing you to focus on the GAME, not the WEB.
Maybe not complete answer but at least it didn't belong to comments. (Doesn't have to be correct)
On Google App engine things that will help:
Users service Will help you with authentication
Oauth on Appengine
The Channel API can help you with realtime sync between players and server
The endpoint's will help you with endpoints for devices if needed
XMPP service offered for sending and receiving chat messages
The above will get you started with a simple game. Recommend to look at the channel api for the tic tak toe game.
I hope it helps
I've made my app running on the Google Glass, but it's a little slow in real time. Is there a way to connect my Android phone with the Glass for data communication, so that the phone can take care of the calculation, and the Glass only show the result? The Glass can tether with Android phone by bluetooth, so it should be able to transmit data via it?
Don't know if it's possible to run my app on cloud server and send the result back to my Glass, but guessing that would be slow as well.
Any suggestion is more than welcome! thanks.
Yes, you can connect your Android phone with Glass for data communication, to receive internet content for example. This can be accomplished using Glass to WiFi (but you need the phone to set this up the first time), or Glass to phone to Bluetooth if your phone supports bluetooth tethering, which is often a carrier option.
If you are a Glass explorer this should have been explained when you picked up your Glass, but you can contact the Glass Guides for more information, if you are a Glass Explorer you will have this contact information. I have found them to be extremely helpful and fun to work with on usability questions. It doesn't hurt that if you visit them physically they ply you with treats and drinks.
If you are asking if you can open a socket directly between phone and Glass, that is not supported functionality, but you can request it. It might be possible when the GDK is made public, but there is no timeline for that.
If you wanted to do calculations on a phone and pass them to glass they would have to go through the cloud, as described here. Check out the section titled "How developers interact with Glass" and the accompanying graphic. I find it to be fast (sub one second with good connectivity), but that is subjective, your speed needs are not well defined in your question. A consideration is that every round trip of data will count against your API console daily limit, which is 1000 for most everyone. There is also a 10 request/second limitation.
Last note - there are unsupported ways of talking directly between Glass and a phone for a device you have direct access to, but this is not supported, and could not be used by other Glass users very easily. The techniques to accomplish this are alluded to in the Google I/O 2013 session: Voiding Your Warranty: Hacking Glass.
This forum isn't an appropriate one to discuss this, if you were to contact me directly somehow I could give you some pointers in the right direction, but I don't advise this route at all.
I have been trying to understand how this problem is solved for over a month now. I really need to come up with a general approach that work. I have a theory, but I'm just not sure it's the easiest (or correct) approach and I haven't been able to find any information to support my ideas.
Here's the scenario:
1) You have a complex web application that offers secure content on a subscription basis.
2) Users are required to log in to your application with user name and password.
3) You sell to large corporations, which already have a corporate authentication technology (for example, Active Directory).
4) You would like to integrate with the corporate authentication mechanism to allow their users to log onto your Web App without having to enter their user name and password.
Now, any solution you come up with will have to provide a mechanism for:
adding new users
removing users
changing user information
allowing users to log in
Ideally, all these would happen "automagically" when the corporate customer made the corresponding changes to their own authentication.
Now, I have a theory that the way to do this (at least for Active Directory) would be for me to write a client-side app that integrates with the customer's Active Directory to track the targeted changes, and then communicate those changes to my Web App. I think that if this communication were done via Web Services offered by my web app, then it would maintain an unhackable level of security, which would obviously be a requirement for these corporate customers.
I've found some information about a Microsoft product called Active Directory Federation Service (ADFS) which may or may not be the right approach for me. It seems to be a bit bulky and have some requirements that might not work for all customers.
For other existing ID scenarios (like Athens and Shibboleth), I don't think a client application is necessary. It's probably just a matter of tying into the existing ID services.
I would appreciate any advice anyone has on anything I've mentioned here. In particular, if you can tell me if my theory is correct about providing a client-side app that communicates with server-side Web Services, or if I'm totally going in the wrong direction. Also, if you could point me at any web sites or articles that explain how to do this, I'd really appreciate it. My research has not turned up much so far.
Finally, if you could let me know of any Web applications that currently offer this service (particularly as tied to a corporate Active Directory), I would be very grateful. I am wondering if other B2B Web app's like salesforce.com, or hoovers.com offer a similar service for their corporate customers.
I hate being in the dark and would greatly appreciate any light you can shed ...
Jeremy
Shibboleth is designed to support exactly this scenario. However it will rely on your customers' companies implementing the identity provider mechanisms. At the moment, that's only really common in universities. Further, if you want user information (any more than just a pseudonymous identifier), you'd need the company to agree to release those attributes to you.
I find it hard to believe that many companies would open their corporate authentication system to you, just to provide SSO.
You might find it better to rely on OpenID or similar, and using a "remember me" cookie to reduce the need for people to enter passwords.
One basic problem with your approach is that you're considering your web app in isolation. Employees at your client's company won't just require SSO to your web app but also some/few/many others, and extending your approach would require a bespoke implementation for each of those to enable access.
Hence the widespread adoption of OpenAthens and Shibboleth in the academic library community to leverage the use of locally-issued credentials. A typical medium/large university can subscribe to various products/services from more than fifty different publishers, and by deploying OpenAthens/Shibboleth they can take advantage of the SAML open standard (SAML is the protocol that Shibboleth uses) that is seeing increased take-up not only in the academic sector, but also in the commercial sector.
John's answer above points to another issue: there are a number of open standards that have recently emerged, SAML and OpenID among them. So content providers are having to decide whether they want to implement some or all of these natively, but they use separate technology stacks and so the implementation and support costs can be duplicated.
Quite a few major publishers have implemented OpenAthens as this supports Athens, SAML/Shibboleth and OpenID in a single platform, with options to plug in other technologies too, or writing a custom module to allow an internal app to connect, e.g. an invoicing or entitlements system recording which clients' users are logging in.
This sector of access management is definitely moving towards open standards, so building your own method would be depriving access to your app for a large number of users
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.