Related
So, the basic idea is this:
I make a request to an assistant app to play some audio.
In general, these requests will come from a Google Home device (I know, they could come from a mobile phone etc, but I'm only worried about Home devices right now).
I can easily send a text response back and have it read.
But what I'd rather do it stream an audio file to the source device via standard Chromecasting stuff.
If I make my request something like
"Hey Google, ask {my app} to read me the instructions for {blah} in the {living room}" then it's no problem to pick out "living room" as the target device and send the audio there. That works perfect.
But if the user says
"Hey Google, ask {my app} to read me the instructions for {blah}"
What i'd like is to be able to send the audio to the device the request came from.
I found this question:
Detect request coming from google home using dialogflow
which is close but not exactly what I'm after.
EDIT: I also found the "MEDIA RESPONSE" info, but it looks like that would only be good for a single media response. In my case, I may have several audio clips that need to play back to back, so a single media response wouldn't work. (at least, I don't see a way it would work from what I know).
Is this even possible?
We currently don't have the ability to treat the Home like a Chromecast through an Action.
However, as you note, we do have the ability to use the [Media Response][1]. As you note, it does only send one audio at a time, however, when it is completed Dialogflow will be called with an Event of actions_intent_MEDIA_STATUS which you can create an Intent to capture. You can then send another Media Response with the next song in the playlist. (Or do whatever else you want as part of the conversation.)
Google Glass automatically uploads every photo I take with it to Google's servers, and puts them in a private Google+ folder. I don't take nude pictures, I'm not a Google competitor and I have no interest in politics, but this is still too creepy for me; I don't want my pictures sent to Google without my approval. After systematically searching all the relevant menus, trying Google's Glass Explorer contact form and their phone support with no luck, I'm looking for a programmatic solution.
I have root access (using the unofficial method provided by Saurik, because the officially published method of unlocking the bootloader doesn't work.) Unfortunately, the relevant parts of Glass's software all seem to be closed-source; there was some noise in the press about it being open, but that turned out to just be the kernel, not the camera app, sync service or anything else. I considered setting up a cronjob to move pictures out of the default storage location soon after they're taken, but that breaks the Timeine. Looking through the list of process names with ps didn't suggest any obvious well-separated target to kill. I haven't configured network-sniffing to identify something to blackhole from /etc/hosts, but I don't consider this very promising because I'm not willing to break the builtin Google Search app.
Rewriting and replacing the entire camera app with one that saves to somewhere Google doesn't know about, seems like it would work; but it's too much work for me. Any other ideas?
EDIT 29Apr2014: With Glass version XE16.2, the auto-backup handling has been rewritten, adding a menu option in Settings to force the image upload to run if you don't want it to wait for it to be triggered by being plugged in with wifi. However, there is still no way to turn the uploader off. Also note that the log-message format has changed; to test whether Glass is uploading images, set up devtools, plug it in, take a picture and run
adb logcat |grep "Upload image/jpeg"
EDIT 6May2014: There is a user report that Glass also uploaded images from a private album on an iPhone that was paired with it. I haven't been able to reproduce this on my Android/Cyanogenmod device, and don't have an iPhone handy to test with; can someone test this for me?
I don't use Google+ and only signed up for it to activate my glass, then disabled it. I was concerned about the same auto-upload issue and contacted support. They got back to me with the following: (SEE EDITS BELOW)
Hey Eric,
In regards to your question regarding Glass's auto-backup policy to
Google Plus, I have received a definitive answer that your content
will not be backed up if you have disabled the Google Plus Glassware
on the MyGlass site or on the MyGlass app. If you have any further
questions, feel free to reach out at 1-800-GLASSXE.
Best,
Bob
Glass Guide
ref:_00Dd0gIrI._500d09YnJT:ref
Edit:
Empirical evidence demonstrates this isn't true though. I was able to click an image in a Hangout and use it to navigate to an album of all images from my Glass.
Click on picture in hangout
Close slideshow (x in upper right corner)
Click "Photos" in navigation bar below the black "Join Google+" banner
Click "Highlights" in navigation bar below the black "Join Google+" banner
I also performed a test as outlined by jimrandomh below:
Enable debug
Enable wifi
plug in with a USB cable
run "adb logcat |grep AttachmentUploader"
take a picture
and the following printed
I/AttachmentUploader( 458): Uploading attachment of 933386 bytes to server, mimeType: image/jpeg, filename: 20131224_094130_897.jpg, source: device:d31658be9793f090
Indicating an image was uploaded to Google on an account that does not have Google Plus, a device that does not have the Google Plus Glassware installed, and the image wasn't shared with anyone.
[Edit] Summary of workaround for benefit of other visitors:
Photos will upload to Google+ "Auto Backup" only when
a) the device is plugged in (charging)
AND
b) the device is in range of connected WiFi
Therefore, if you do not want any photos uploaded, move them off the device before charging while connected to WiFi.
[Original]
I understand that you are looking for a programmatic solution. However, you have indicated that you have tried non-programmatic options (menus, contact form, phone support).
So here is a proposal: The Auto-uploading seems to be "connected" to and enabled by Google+. So "dissociating" the Glass device from your Google+ glassware component in the Glass companion website, seems to be disconnecting the auto-uploading. Testing this, even after a few hours of Glass in charging and in range of WiFi, no photo uploading took place. So this is something that you could try.
Try to find the google servers, and add that servers as entries to the /etc/hosts file pointing to 127.0.0.1, so every time it upload a photo to googleglassgoogleplusuploadserver it connects to localhost and rejects the connection.
Sadly I don't have any glass to try :-(
Since you are able to code for the glass API, you must be familiar with g+ API and similar things... You can write some code which will back the photos from g+, to your own servers... You then can get from there for any glass activity... (you should also delete from the glass, and g+ otherwise it will be available once you go to g+ - it will fetch as if your photos are their assets.)
This glass I believe, is not concerned of human intentions but they just wish to expand their crawl database as if a micro camera is pinned to a bird which automatically sends all it sees to us. Here, one should understand that we don't love birds, but we only wish to get the information without ourselves exploring all the wild places.
I'm not a programmer, but have the same concern. I've decided to disconnect it from my phone and wifi when I want to take private pictures. I can use Windows Explorer to copy them over, then delete them from Glass. Reconnecting it is a pretty quick process. It's a bit of a hassle, but allows the device to be used privately.
I'm new in Adobe Air, I need (urgente!!!) to do a widget with Adobe Air that monitors the URLs where I navigate and when I enter to a specific site the widget appears in the front of my screen and display a message.
The problem is that I don't know how to listen the current URL of my browser using Adobe air (flash).
I was trying with HttpStatusEvent but I can figure aut how to retireve the URL from my browser.
Thanx!!
Carolina
See my answer to this question
This wouldn't be easy; it may be impossible. There are issues with timers and running AIR/Flash Player minimized. Things slow down so it is less of a drag on computer performance. AIR in the background may not respond the same way as an Active AIR application would.
In theory, you can write a Proxy in AIR using sockets and set the local browser to route all requests through the proxy. That probably isn't practical for wide use.
If you have control over the web page that you want to use to trigger your AIR app, you might be able to put a SWF on your web page and then use a LocalConnection to communicate between the browser SWF and the AIR app, forcing the AIR app to pop up.
AIR has no means to know if browser is running and what it does (barring NativeProcess helpers).
Flextras' answer made me think about proxies... Of course, proxy inside widget isn't practical. If widget is proxy, you can't have internet without it - that's silly. Instead, one can take an open source proxy, inside it check user agent header (to filter browser requests) and probably url (to exclude images, css and js requests). When you have request from browser and for html, you can make proxy open local socket connection to the same port your widget listens and notify it. But this can hardly be done urgently.
Can anyone tell me why the Range, header is restricted in the Flash player?
I want to be able to pause and resume downloads in my flex application, but I get a RTE when trying to set the Range header.
Error #2096: The HTTP request header Range cannot be set via ActionScript.
I imagine there isn't going to be a work around client side, but expect there is a way you can get a server to change the name for the range header to something else...
Would like to know Adobe's reason for this though, hopefully it's not just to sell more copies of FMS :p
I just discovered exactly the same issue with the Range header while attempting to add ranged GET requests to our REST layer in Flex. Range is on the "blacklist" and the Flash Player simply won't send it.
Flash/Flex headers ate my brain a year or so back (verveguy.blogspot.com) but this is the last straw.
The solution I am now going to finally embrace is to use the open source as3httpclientlib and just abandon the Flash HTTP stack. We've used it successfully for some minor parts of our app (specifically, for talking to the JIRA API) so it's time to beat it into submission for all HTTP traffic.
For your specific problem, you could certainly switch to a custom header, say X-Range. This assumes you have control of the server side code and that you also have a crossdomain.xml policy file that allows headers. (Blacklisted headers are the first set to be culled. After that, the Flash player checks the crossdomain.xml advertised by the server you're talking to see whether it allows specific (or all other) headers)
Hope this helps
Here are a couple of Adobe Tech Notes that explain their reasoning:
Arbitrary headers are not sent from Flash Player to a remote domain
ActionScript error when an HTTP send action contains certain headers (Flash Player)
I want to at least prevent normal users to download my flash video.
What's the best way to do it?
Create a httphandler, add a token (e.g. timeid), set the cache control to no-cache so that only the users with correct token can view the correct video. Is that feasible?
It is the requirement from client that the video should not be downloaded by users and should be watched only in the particular website.
I want to know if this works:
http://www.somesite.com/video.swf?time=1248319067
Server will generate a token(time in the above example) so that user can only have one request to this link. If the user wants to watch the video again, he needs to go to our website to get the token again. Is this okay to prevent novices from downloading?
I can't download this flash video by the downloadHelper firefox plugin:
http://news.bbc.co.uk/2/hi/americas/8164177.stm
Updated (13:49 pm 2009/07/23):
The above file can be downloaded using some video download software.
The video files of following Chinese sites are well protected (I can't download it using many video download software):
http://programme.tvb.com/drama/abrideforaride/video/
Do you know how it is done?
I dont think there is an easy way to stop people from getting your videos if they want them,
there are plenty of plugins for firefox that allow downloading from even youtube and many places. And i imagine those plugins would disable any attempt you made to hide your videos.
not too terribly different than taking an image from flicker, they put a clear gif image over the image that you want to view, so that when you right click and save you get "the shield" image, however can be defeated by the lowly print screen button.
if you want casual users from getting your file, use a flash control and buffer a minute or two of your videos and make that flash authenticate with the server to get those files. that seems reasonable to me
I don't think there really is an easy way to limit people from getting at it. Your sending them the video, that is how they are able to view it. Any user could just use FRAPS or a similar tool to copy the video from the screen as well.
If your worry is being copied and used elsewhere then you can watermark it or use a few other types of copy protection methods that will allow you to identify your work on other sites. If your worried about people copying it for personal use, then you really have no way of stopping it, you are sending it to them.
Edit: Due diligence would be to inform your customer of how easy it is to copy the work that they will be posting. Most clients have really no idea how easy it is.
This is how I like to tackle this issue.
This method works by creating a ticket to download the content over one http request...Another attempt to use the same ticket to download the content will fail, hence any extensions that attempt to download the content again or a user manually attempting to fail to do so, hence the flash player will be the only way to download the content. However there is one downfall for this approach, users will not be able to skip to a part of the video that has not been download...in some standard player implementation that may even stop the video from loading. Any ideas on this will be highly appreciated.
I begin by writing a PHP script that takes in a video_id, file_name, or a local path to your video file (Depending on the storage infrastructure of your video collection) in a GET request along with a unique hash value (a hard to guess and come up with probably generated with a secret key so it can be validated to be coming from our reciever (flash player), if the hacker send us a used hash or an invalid hash (does not satisfy our key), we will not send him the file). The PHP script then opens the video file and sends its content with the correct video mime type. for FLV the mime type is video/x-flv. It makes sure that once a unique hash has not been used before and is validly generated from your secret encryption key.
Then once the page with the flash player is loading we can give the .php file with the right get parameters as the video url to the video player. (If it is a prude player that only allows flv files you can always program your .htaccess file to parse .flv files as php script in the specific folder only, and rename your .php file as .flv and try your luck)...anyways...Also generate a hash key...perhaps you can take the servers current time and append it to a salt value such as another key known by both scripts, and encrypt this final concatenation with your secret key.
So once the video gateway php script will recieve a filename or hash key...it will decrypt the hash key and figure out if it is validly generated from teh sister script, and make sure not to send the video again to the same hash key...
For added security you can perhaps reset the secret key everyday using either a cronjob or bootstrap mechanism. To prevent duplicate use of hashkeys you can store them in a mysql database, file operations, or NOSQL (depending on your needs and infrastructure).
Make sure that the file is requested by the same user agent the hash key was generated for. In case the hacker trys to cURL or Wget your videos unused url before the flash player gets a chance to consume the hash key. In this case the hacker will have to imitate the browser's user agent or download the file using their command line tool as well...However please note that this is not your average champ.
It sounds like you need to add authorization and authentication.
You could put the flash video under a different folder in your ASP.Net application and add a web.config file in that folder to deny access to unauthorized users. For example:
Then you need to enable authentication for your website. The simplest method is forms authentication. A trivial example with hard coded username and password is provided here.
There is loads that you can do with the authentication framework in ASP.Net I suggest googling a bit.
The only way to do this is with a trusted client, DRM and an encrypted source.
Your player opens up a connection, the user has a connection to the stream, you perform some magic authentication with their token and then transmite the encrypted data to them.
If you don't do this then anyone can download your video and save it out.
However with all that aside, someone can run screen capture, then save your video and do it again. This is again where the DRM comes in as one of the key features of the DRM in windows clients is that the buffer cannot be sniffed as it's on the protected media pathway.
I guess its a question of how to protect your revenue but dealing with pirates is always going to be a problem for software devs no matter what their business is.
I have a solution that i'm gonna try for myself (as I have the same worries) but I know that it includes a lot of extra time and work...
Solution: using flash compress the video into an swf file. Before compressing add some AS code to the movie for authentication. suggestions for authentication:
1 test url
2 create a dedicated flash player that has handshake code checked by the video.swf
I like #2 better, and as an extra measure, you can overlay an id code over the video, so if someone captures the video using screen recording software, you'd at least be able to track the original source of the copied video.. and exact suitable retribution...
Simply you can't prevent it.
But..you can make it difficult.
Here some ideas come in my mind
1 First of all add your identifier to the video (always someone can download it)
2 The hard way... Add Ajax call back to server to check a random generated key that it will stored in the session every N seconds. After every post back clear the buffer of the player and start the video from were i was (using javascript).
Use again JavaScript prevent the video source from downloading by "view source".
3 Handle all your videos in urls like http://www.example.com/viewvideo/1 OR ../?id=1.
Add blank image overlay with transparent background.
Serve the original video and a blank video somewhere on the page with normal extension and style attribute "display:none". (will create problems to some download helpers)
4 Everytime you serve a video CHECK if the request is from a browser (ie check UserAgent)
5 Cookie with some random value combined with the id of the video. Check it client-side and server side and then serve the video.
6 On focusout event hide the video with javascript. put a resume button in the flash and leave the frame unchange (like pause but with no original video in buffer).
7 Combine those methods
these are random generated ideas,
not tested neither i say that guaranties no video downloading.
I have attempted two way to prevent the downloading but fails.
Using javascript to dynamically generate the object for flash.
Using the token idea proposed in the question.
What annoying me most is that a simple SAVE/AS from the firefox browser could easily bypass the tricks.
The only variable way so far is to using an empty swf file to load another swf file in. Combined with the token idea, it works.
in my answer you cant stop image/video theft but you can make harder for normal users but you can't make it harder for the programmers like us( i mean thiefs that knows little web programming) there are some tricks you can try:-
1.) Using flash as youtube and many others sites like http://www.funnenjoy.com does .
2.) Div overlaping or background pic setting (but users with little sense can easily save all resources by opening inspect element or other developer option).
3.) You can disable right click and specific keys like CTRL + S and others possibles with JAVASCRIPT but main drawback is that if user disable JAVASCRIPT our all tricks fail down.
4.)Save image in none online directories(if you have full access to web server) and read that files with server side languages like PHP every time when image / video is required and change image id time to time or create script that can automatically change ID after every access.
5.)Use .htaccess in apache to prevent linking of your images by others sites. you can use this site to automatically generate .htacess http://www.htaccesstools.com/hotlink-protection/