I was just dabbling a little with the Instagram API and noticed that all the media links (e.g. image / video URLs) that point to the fbcdn are publicly accessible.
I usually try to use signed URLs for user-generated content and was wondering why Instagram apparently is not choosing to do that?
If they would do that, the URLs that are used to render the webpage or the app for example could only be valid for a couple of minutes so if someone should collect them (for example to scrape user profiles) they wouldn't be accessible anymore afterwards? I know this is not perfect but it feels like it would at least give the privacy aspect a little extra notch...
Related
I am very confused as to how Safari 2.3 works in certain respects, and why sites can’t easily circumvent it. I don’t understand under what circumstances limits are applied, what the exact limits are, to what they are applied, and for how long.
To clarify my question I broke it down into several cases. I will be referring to Apple’s official blog post about ITP 2.3 [1] which you can quote from, but feel free to link to any other authoritative or factually correct sources in your answer.
For third-party sites loaded in iframes:
Why can’t they just use localStorage to store the values of cookies, and send this data along not as actual browser cookies🍪, but as data in the body of the request? Similarly, they can parse the response to updaye localStorage. What limits does ITP actually place on localStorage in third party iframes?
If the localStorage is frequently purged (see question 1), why can’t they simply use postMessage to tell a script on the enclosing website to store some information (perhaps encrypted) and then spit it back whenever it loads an iframe?
For sites that use link decoration
I still don’t understand what the limits on localStorage are in third party sites in iframes, which did NOT get classified as link decorator sites. But let’s say they are link decorator sites. According to [1] Apple only start limiting stuff further if there is a querystring or fragment. But can’t a website rather trivially store this information in the URL path before the querystring, ie /in/here without ?in=here … certainly large companies like Google can trivially choose to do that?
In the case a site has been labeled as a tracking site, does that mean all its non-cookie data is limited to 7 days? What about cookies set by the server, aren’t they exempted? So then simply make a request to your server to set the cookie instead of using Javascript. After all, the operator of the site is very likely to also have access to its HTTP server and app code.
For all sites
Why can’t a service like Google Analytics or Facebook’s widgets simply convince a site to additional add a CNAME to their DNS and get Google’s and Facebook’s servers under a subdomain like gmail.mysite.com or analytics.mysite.com ? And then boom, they can read and set cookies again, in some cases even on the top-level domain for website owners who don’t know better. Doesn’t this completely defeat the goals of Apple’s ITP, since Google and Facebook have now become a “second party” in some sense?
Here on StackOverflow, when we log out on iOS Safari the StackOverflow network is able to log out of multiple sites at once … how is that even accomplished if no one can track users across websites? I have heard it said that “second party cookies” still can be stored but what exactly makes a second party cookie different from a third party?
My question is broken down into 6 cases but the overall theme is, in each case: how does Apple’s latest ITP work in that case, and how does it actually block all cases of potentially malicious tracking (to the point where a well-funded company can’t just do the workarounds above) while at the same time allowing legitimate use cases?
[1] https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
I am aware of the update to Instagram apis. I have read through the documentation regarding fetching hashtag images. I'm confused regarding 2 points -
They have a section "Endpoints", which gives the url for fetching images using tags - https://api.instagram.com/v1/tags/{tag-name}?access_token=ACCESS-TOKEN
At the same time, when i try to submit for review (under Permissions Review section), in order to get access token, i get this message -
"This use case is not supported. We do not approve the public_content permission for one-off projects such as displaying hashtag based content on your website. As alternative solution, you can show your own Instagram content, or find a company that offers this type of service (content discover, moderation, and display)."
The 2nd point makes me believe that Instagram has stopped sharing hashtag images to apis, at the same time i can find a lot of widgets still fetching hashtag images. How do they do that? Can anyone point me in the right direction?
The 2nd point makes me believe that Instagram has stopped sharing hashtag images to apis,
Correct. Instagram has made business decision to block most developers from accessing this content.
at the same time i can find a lot of widgets still fetching hashtag images.
This doesn't tell you much. They might have gotten their app approved for other purposes. Also it appears that Instagram has made some exceptions for big apps (like Tinder). Life is not fair.
How do they do that? Can anyone point me in the right direction?
You probably cannot. 99% of the use cases are not allowed and so they will reject your app if you try to submit it. Read this short article about what you can and cannot do with the new Instagram API
The other widgets you are talking about probably have presented Instagram with one of the valid use cases to fetch the data. They are able to get only the public content. This new restriction is probably a business decision. If you would still want to get the data you are looking for, you shopuld possibly go to a third party data provider who sell such data
I can't seem to find any documentation or reference on upload and sharing images on Google+.
Is this action current supported in google+?
Their moment sharing seems to accept thumbnail url, but I don't want to keep the image hosted on my site once it is created and shared by visitor.
You have a few different options, but I'm not sure any of them are really what you're looking for.
Google+ doesn't really allow outside apps to upload and share something automatically.
As you've observed, the closest you can get is generating a Moment for them to share. And while there are similarities to Instant Upload, it isn't identical. You could probably use a data url to encode and store the image as part of the moment, but I haven't tested this.
Another alternative is to use the Google Drive API to store the image in their Drive space, permit the image to be read publicly, get a link for it, and use this link as the thumbnail URL. Similarly, you might be able to use the Picasa Web Albums Data API to store the image. Both have good, but different, integration with Google+. The former is more modern, while the latter has more features that are tailored for images.
I'm currently working on a Google Hangouts app that, among other things, features posting links to certain pages on the user's Google+ page.
Because the shared content is mainly a visual thing (dynamically generated images, to be precise), I have been looking at ways of having the post
on user's stream display a big, full-width picture, essentially an effect similar to one visible here (disclaimer: I do not endorse the company linked in any way, it was simply one of the first examples I have found of the look).
Now, I've read through Google+ documentation on Share Button and Snippets about ways to have sharing from a single click and customisation of the content that comes with the link, but visually, the attached thumbnail is somewhat smaller than what I'd find ideal for the task (as visible ).
The example of a big picture display was tied to the photo sharing functionality, so I've looked at Google+ API, to see if there's a way to automate it, but as stated on the API docs landing page, "The Google+ API currently provides read-only access to public data.". No ability to pursue the goal through the official channels then.
Next step, GitHub. There are some sites for which the wrappers around their internal communication have been written, thus creating sort of unofficial API, so I tried my luck there. Among various libraries, I have found one that was not a wrapper around an official API, google-plus-extension-jsapi, but being written for the context of Chrome extensions rather than webpages, I couldn't get it to work, mainly due to usage of WebSQL and cross-domain XMLHTTPRequests.
Without any further leads, I ask the community thus - is there any way for a webpage app to provide the user with the ability to share a full-width picture on their Google+ stream or am I limited to standard sharing thumbnails?
I will confirm, you can not do what you're trying to do using the Google+ API because there is no stream write API and you do not have control over how shares will render.
As you have already determined, you can not write posts, such as a picture, directly to a user's stream, without the user's interaction (e.g. share). For branded pages, there is the Pages API, but it is currently not public and would be restricted to Pages as opposed to People/Profiles.
You can generate a share link to an external image and then if the user clicks it, the image can appear in their stream. As you noticed, the image will be a small thumbnail as opposed to a full-bleed photo and will render as a share - undesirable if you want the image to fill the whole stream area.
I wrote a script that uses the Google Images JSON API to automatically fetch thumbnails for posts. I'm currently linking directly to the thumbnail (eg. http://t3.gstatic.com/images?q=tbn:ANd9GcTok4m3DWNRv8gxMDTE0bwj8m-jYl2UGdlbc7ig158m0XosD-lcQEIFcg). Does Google allow that?
If not, I should be allowed to download the thumbnails to my server right?
Its all about traffic. If your app will make tons of traffic, they can ban your server.
Anyway, better/best way is to ask them about this subject.
Also this might help you : Google Terms of Service Highlights
I see problems when you download the image thumbnail to your server and render. Images shown in search results might be copyrighted/inappropriate. They are crawled images so the owner can request google to remove at anytime. On contrary, if you cache them locally and render, I see the workflow is broken and you might be rendering image that ideally should have been revoked.
Coming back to hot linking, can you explain bit more on the actual usage context. What API you are using, what are you searching at, do you own the website / posts that you are filtering?
Also image search API is deprecated one. By terms it would be active only for three years since notice.