When submitting an app to the Mac App Store it's asking me this questions:
Content Rights
Does your app contain, display, or access third-party content?
Do you have all necessary rights to that content or are you otherwise permitted to use it under the laws of each App Store territory in which your app is available?
My app uses the Safari component to display web pages, so, it can display third party content, and I believe I don't need any permission to do so the same way any other vendor doesn't need permission to produce a browser.
Using the component to wrap an entire site to make it look like an app and present it as your own is probably an "offense". But clearly showing that web pages are loaded and displaying them as they were intended by the website creators could not be an offense. It would go against the entire structure of the WWW.
If some people actually do put websites on the publicly accessible web and want to keep it private they did something wrong to start with :). It can't be the responsibility of each and every browser developer to keep track of that.
And a browser is a browser, if it's on a mobile device or a desktop.
So it would be ground breaking if this would be judged otherwise. And if it was, it could probably easily be contested. Not to mention the sh*t storm that it would start online if this was their public stance :)
The only source I could find on it is here, where it says that it is "most likely to affect apps which use the brand names or logos of other companies". You are not displaying third-party content, you are displaying a browser. Unless that browser window is filling up the entire screen (so that it seems like they are not seeing a webpage) and you make it seem like that website is part of the app, I can't see why they would stop your app.
I would think that you don't need to say that you access third-party content at all, and if Apple disagrees then they may pull your app. But as you say, it would be the same as every browser app. Either the safari component is third-party content, so no browser should be allowed as they show content that they do not own, or it's not third-party content and you should be OK.
If what you are trying to do is displaying any webpage on your own browser using the Safari component you already have the rights to display it. If the owner of the content doesn't want you to display it the webpage would require a username/password to access the content. This is an implicit "contract" when you create a public site on the internet, anyone can see it/use the information provided. If there is an explicit ban of some domains due to government laws your application will not be able to access the site from that location (like use to happen on some mid-east countries/china) but the block will be on the physical network and you don't need to worry about it.
If you can access the domain from the application in any given location, you can display the content "as is" without any modification or claim of property, this is probably not obvious but you cannot claim that you produced the content, you can however display it and use it. IF the site has a protection requiring the user to provide a username/password, you can still display the login/home webpage without any explicit permission, this permission is already granted because it is public. Once the user of your application inputs a username/password "his" session will be granted the required permission to access the remaining content, again since the server sends you the information you can still display it "as is". In the case that your application stores the username/password for later access you need to explicitly inform the user about this, moreover he needs to agree on that. You can use those credentials to access the site later for that user. You cannot store the username/password to automatically login a user different than the owner of the account nor use yourself the contents of the protected webpage trough any means (i.e. scraping and storing for later use).
In short, if you can access the website you can display it as is and that's legal. If the site is protected you can still display what the server sends you (probably home page + some login webpage/option). You can let the user interact with the webpage like any other browser does and he can log in to the protected webpages and you have the right to display that content for that user, not to store it or duplicate/publish/etc.
You can not: show a webpage and claim you built it, unless you have explicit permission from the owner/legal representative of the webpage to do so. You can't even change the webpage to "disguise" it is as something that looks like you built it, without you claiming you did.
For a regular browser-like interaction with internet in general, you already have the rights to display the contents of the webpages that are publicly accessible.
Hope it helps!
According to Wikipedia
On OS X, Safari is a Cocoa application.It uses Apple's WebKit for
rendering web pages and running JavaScript. WebKit consists of WebCore
(based on Konqueror's KHTML engine) and JavaScriptCore (originally
based on KDE's JavaScript engine, named KJS). Like KHTML and KJS,
WebCore and JavaScriptCore are free software and are released under
the terms of the GNU Lesser General Public License. Some Apple
improvements to the KHTML code are merged back into the Konqueror
project. Apple also releases additional code under an open source
2-clause BSD-like license.
LGPL ?!
The GNU Lesser General Public License (LGPL) is a free software
license published by the Free Software Foundation (FSF). The license
allows developers and companies to use and integrate software released
under the LGPL into their own (even proprietary) software without
being required by the terms of a strong copyleft license to release
the source code of their own components. The license only requires
software under the LGPL be modifiable by end users via source code
availability.
You are allowed to display any content you wish , Unless the content has copy rights from 3rd party , only then that 3rd party has the right to claim its rights , assume you are displaying a pirated movie produced by Warner Bros in your app , only then this will be illegal , but still is out of Apple's scope.
Under Content and Intellectual Property Rights (guidelines)
8.5 Apps may not use protected third party material such as trademarks, copyrights, patents or violate 3rd party terms of use. Authorization to use such material must be provided upon request
You aren't doing that. You are allowing your app to utilize safari, what the user does from there falls under the same guidelines they accept when they utilize safari. You are just extending your app to use safari. You aren't granting anyone access to content you aren't allowed to use, you're not facilitating the bypass of any locked content, etc.
This can be found on: https://developer.apple.com/app-store/review/guidelines/
Related
i am hosting a site in Joomla and we want to allow document downloads. however, we want the downloads only after user submits at least their email.
i searched and found that it could be possible to do this by means of user registration but is there a simpler way by means of a plugin that allows simple user email submission followed by download over full registration.
You can try DocMan, which is a Joomla document management extension. The only issue is that this is a commercial, and it costs $99 for one website. But it is a solid extension.
Don't waste your time writing code to do what you want to do when an extension may do.
For the background:
I'm developing a device application which offers connection to Google Drive. My end-users will need to login to their Google Account and authorize my application to access their Google Drive.
I'm using OAuth 2.0 to do this. But my concern is that I don't want users to navigate away from my application using the links on the Google Login page. Basically, I don't want them to use my application to browse the internet.
Question:
Will I violate any terms of service/usage if I hide or change the href the links using GreaseMonkey or TamperMonkey? The changes will only be on the client side and I won't alter any processing at all.
I already checked https://developers.google.com/terms/ but I found no item related to modifying the pages on client side.
Thanks in advance.
What kind of device? If you’re on Android, check out the Google Drive API and GoogleAuthUtil, you probably don’t need to code your own OAuth 2 support. On iOS we’ve been shipping a bunch of library-ware to help you similarly.
But if you’re doing OAuth 2 via a browser, it would be highly inappropriate to screw around with the Google Login page. Also I suspect that the page will try to resist such attempts, but I don’t know the details.
I want to submit my first app to the windows market place but while trying to find out the certification process I become confused if I need an about page (that contains support information) or not.
Yes you do need to include some information which is probably best to have on an about page. See 5.6.1 in certification requirments
An app must include the app name, version information, and technical
support contact information that are easily discoverable.
If you use the location API you will need to have a privacy policy in the app or linked in the app (requirement 2.7.2, also 2.7.4 is relevant):
The privacy policy of your app must inform users about how location
data from the Location Service API is used and disclosed and the
controls that users have over the use and sharing of location data.
This can be hosted within or directly linked from the app. The privacy
policy must be accessible from your app at any time.
Same goes for if you upload pictures, contacts etc from the app (see 2.8).
Ofcourse this information does not require a dedicated about page, but as they write, should be easy to find for the user.
And if you don't want to spend to much time on your about page and still want it to look great, take a look at this opensource project!
http://ylad.codeplex.com/
It comes as a nuget, so easy to add in your wp7 project! http://nuget.org/packages/YLAD
I'm currently working on a rather interesting... project. I have a client who wants to allow form uploads (from a page presented on their server) specifically to their own google drive account. The platform being used is essentially LAMP.
Single (pre-authenticated) google drive account. Multiple otherwise anonymous upload sources (users).
They do not want users to be required to have their own google accounts (rules out simply using Picker on the user's own drive files).
They want some degree of backwards browser compatibility, such as IE8 (rules out XHR to form the post using HTML5's file API to read the filedata). They don't want to use flash/etc due to potential compatibility issues with certain mobile browsers.
What is working:
Authenticating (getting a refresh token, storing, using it to get access tokens as needed)
Uploading a file to the account without metadata
Result of file upload being sent to hidden iframe
Catching the iframe load event via jquery to at least know something has happened
Problems:
The REST API upload endpoint does not support CORS: there is no way to access the result iframe directly. (see: Authorization of Google Drive using JavaScript)
The return from a successful upload is only raw JSON, not JSONP.
There is seemingly no way to host anything with proper headers to open via browser on the googleapis.com domain, so easyXDM and similar multi-iframe with cross origin workaround communication javascript approaches are ruled out.
There is no way to embed a callback URL in the POST from the submit, the API does not allow for it.
The Picker displays errors on trying to upload if you pass it an Oauth2 token that is not for a user who is also authenticated in their browser (assumedly via cookie). Strangely enough you can show files from the Oauth2 token's matching account, but other than in a browser instance where the target Oauth2 token's account matches the already logged in user any file uploads fail with an ambiguous "Server rejected" message. This happens with all files and file types, including files working in an authenticated browser instance. I assume it's an authentication flow/scope issue of some sort. I haven't tried diving the Picker source.
All of the javascript Google Drive API upload examples seem to rely on using HTML 5 to get the file data, so anything of that nature seems to be ruled out.
While files are uploaded, there's no way other than guesstimating which file came from which user, since we can't get the file object ID from the result in our inaccessible iframe. At best we could make a very rough time based guess, but this is a terrible idea in case of concurrency issues.
We can't set the file name or any other identifier for the file (not even a unique folder) because the REST API relies on that metadata being sent via JSON in the post request body, not via form fields. So we end up with file objects in the drive with no names/etc.
We can't create the file with metadata populated server side (or via jquery/XHR, or the google javascript API client) and then update it with a form based upload because the update API endpoint exclusively works with PUT (tested).
We can't upload the files to our local server and then send them to google (proxy them) as the php ini is locked down to prevent larger file uploads (and back to restrictions imposed on using HTML5 or flash for why we can't chunk files/etc).
All of this has been both researched and to varying degrees tried.
At the moment this is going on hold (at least it was a useful way to learn the API and gain a sense of its limitations) and I'm just going to implement something similar on dropbox, but if anyone has any useful input it would be lovely!
e.g. is there any way to get this working with Drive? Have I overlooked something?
I also realize that this is probably essentially a less than intended use-case, so I'm not expecting miracles. I realize that the ideal flow would be to simply allow users to upload if necessary to their own google drives and then have them grant file access to our web app (via Picker or API+our own UI), but this becomes a problem when not all of our own users are necessarily already google account users. I know that google would OBVIOUSLY prefer we get even more people to sign up with them in order to have this happen, but making people sign up for a google account to use our app was ruled out (not out of any prejudice on our part, it was just too many added steps and potential user hurdles). Even simply having them sign in to google if they did have accounts was deemed unwanted for the basic LCD feature functionality, although it's likely to be added as an additional option on top of whatever becomes the base solution.
The biggest problem with the approach you described is you're introducing a big security issue. Allowing an anonymous user to directly upload to Drive from the client requires leaking a shared access token to anyone who comes by. Even with the limited drive.file scope, a malicious or even slightly curious user would be able to list, access (read/update/delete!) any file that was uploaded by that app.
Of course a public drop box feature is still useful, but you really need to proxy those requests to avoid revealing the access token. If your PHP environment is too restrictive, why not run the proxy elsewhere? You can host a simple proxy to handle the uploading just about anywhere -- app engine, heroku, etc. and support whatever features you need to ensure the metadata is set correctly for your app.
I am developing my first application using the Composite C1 CMS as the core system. I am currently working my way through the documentation and learning about data structuring, etc. I see that there is a paid Extranet package which can be purchased but I would prefer to develop my own Membership system within the site.
What would be the best way for me to allow users to register on the front end of my Composite C1 website and then to allow them access to a password protected area once they have registered and logged in?
I am a fairly experienced .net developer but Composite C1 is very new to me (at first impressions I like it a lot!)
Thanks
Like the commercial Extranet package you can write a RenderingResponseHandler plugin and register it it the ~/App_Data/Composite/Composite.config file.
Check the guide "How can I validate users before a page or media file is being served?"
RenderingResponseHandler plugins are tasked with approving page and media requests and they can either let the request pass or redirect the request to a new URL.
You would need to take care of the user data base and login page yourself. Also some mechanism that would allow a user of the cms to mark pages as protected/public might make sense.
There is relevant pointers on the CodePlex thread "Restricting access to MediaArchive files"