I'm using a online web builder to create my website. Once the site is published, it automatically sets their (web builders) third party cookies (google analytics, etc). There is no way to disable it in the platform.
However, under the new EU law, you are not supposed to download any cookies to the users computer, without their prior consent.
I can modify the header html code. Is there a way to generically block all cookies in the html header of my webiste?
Is there a way to generically block all cookies in the html header of my webiste?
No.
If you think your hosting service is exposing you to legal problems, then don't try to hack around them, either talk to them so they fix the problem or find a new host.
Related
I have created a game in google sites and would like to use cookies to track the player's highscore. I am not sure if google sites allows cookies in embedded html. I checked the code of the google sites page and figured out that my embedded html is actually stored as an iframe, which as far as I know, does not allow cookies.
It will be difficult to implement it since like you said its in an iframe and the domain of the iframe is dynamically generated. A similar issue is raised here. An alternative option would be to create a web app on firebase and link it with your google sites, but this could be slightly different from your initial idea of keeping track of user's score on the browser.
I have a static website, it only contains html and css. No javascript, no php, no databases. On this site, I'm using images, which I get from image-hosting websites (like imgur).
I've noticed when I visit my website (on Google Chrome at least), if I click the information button next to the URL, it says there are cookies on this site. If I click on the cookies button, it says The following cookies were set when you viewed this page and has a list from cookies, including from those sites that I use for image-hosting.
If I delete them, they come back after a while, but not immediately. I'm trying to avoid cookies as the site is very simple. Are they considered part of my site? If so, is there anything I can do, except hosting the images myself?
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Are they considered part of my site?
That depends on your perspective.
The browser doesn't consider them to be part of your site. Cookies are stored on a per-domain basis, so a cookie received in response to a request for an image from http://example.com will belong to http://example.com and not to your site.
However, for the purpose of privacy laws (such as GDPR) then they are considered part of your site and, if they are used by the third party to track personally identifiable information, you are required to jump through the usual GDPR hoops.
If so, is there anything I can do, except hosting the images myself?
Not really.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Cookies are generally set with HTTP response headers, not with JavaScript.
Whenever a browser requests a file from a server it automatically forwards any cookie data along with the request. Image Hosting services may use that for different purposes.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
So the question is, how to they set these cookies?
Let's say, you use a simple img tag to load an image from a hoster.
<img src="imageHoster.tld/123xyz.png">
The site imageHoster.tld can handle that request by redirecting all requests to e.g. requestHandler.php and that file can set the cookie before sending the image with a simple
<?
setcookie("cookieName", "whateverValue", time()+3600);
header('content-type: image/png');
...
?>
What happens there is actually the same as if you would set the image source like that:
<img src="imageHoster.tld/requestHandler.php?img=123xyz">
Are they considered part of my site?
Since these so called third party cookies are set when visiting your site one could consider them as part of your site. To be on the safe side I would at least mention the use of third party services in the data privacy statement.
If so, is there anything I can do, except hosting the images myself?
Third party cookies can be disabled in the clients browser. But you can't disable them for the visitors of your site. So no, to avoid third parties setting cookies on client browsers visiting your site you can only avoid using their services.
I have a service and would like clients to be able to place this service on their website. I am looking at doing this by using an iframe. I will provide the code and they can just copy and paste the code to show the functionality. Each client will be discovered by the query string.
There is a concern that anyone can look at the source of the website, copy the iframe and add it to their own website therefore using the service and charging the original client. I obviously want to stop this.
Ideally, I would like to verify that the website that is using the iframe is linked to the client who registered to use the service. Is this possible at all? I know there are issues with cross domain security.
If it isn't possible, I guess I would need to create a widget instead.
For each client, have a whitelist of web sites that can embed the iframe. Then check the 'referer' header against that list whenever the page inside the iframe is loaded.
Or if http headers prove to be unreliable try using javascript, via parent.document.location.href
I have a joomla installation which I have installed aceshop onto. I have also setup an SSL for the checkout page as that is the only area I want or need to have secured for ssl.
The problem im getting is with Google Chrome. Because the checkout page is in SSL, and the css/js references aren't, Chrome is blocking the css. You have to override the security setting for the page to display it properly.
Anyone know how to fix this problem? I DON'T want the rest of the site under sll, just the checkout page.
Thanks!
You need to serve your CSS/JS over SSL as well. If you don't, it doesn't matter that you have served the page over SSL. In that case, a man-in-the-middle attacker can add arbitrary JavaScript, which will execute in the context of the checkout page, where it can steal all the information that the user types (name, address, cc, whatever).
If you want your site to be secure, you need to fix all the mixed mode content problems, otherwise it is equivalent to having no security at all.
A client of mine has a full-Flash site and an HTML site (wordpress). Currently, the HTML site lives at http://www.domain.com, while the Flash site lives at http://www.domain.com/flash (swfobject detection at http://www.domain.com redirects flash users to the flash URL). The client isn't entirely pleased with this arrangement in terms of SEO, as links to their site sometimes point to http://www.domain.com and sometimes to http://www.domain.com/flash.
In a few weeks, the client will be rolling out a new version of their Flash site, which features deeplinking, among other things. Instead of living in its own folder off of the domain, the full-Flash site will be a "progressively enhanced" version of the HTML site, so if a user supports Flash, all HTML content will be replaced by Flash content.
Once the new site is launched, each page/URL in the Flash site will have a corresponding HTML page/URL; for example, the Flash content at http://www.domain.com/#/about/clients corresponds to the HTML content at http://www.domain.com/about/clients.
We're going to implement a 301 redirect so the old /flash path points to the domain itself, but we're not sure how to proceed in terms of redirects between the HTML and Flash versions of the site. One possibility would be to simply do client-side detection of capabilities and redirect the user to the appropriate version; under that scenario, a non-Flash-capable client that attempts to visit http://www.domain.com/#/about/clients would be JS-redirected to http://www.domain.com/about/clients, and a Flash-capable client visiting http://www.domain.com/about/clients would be JS-redirected to http://www.domain.com/#/about/clients.
Is this a reasonable approach? Are there any potential SEO red flags that we should be aware of before proceeding?
Thanks for your consideration!
The redirect from /#/about/clients to /about/clients sounds reasonable, but applying the reverse could cause problems - if your Flash detection doesn't work correctly (perhaps Flash is blocked etc.) then you may send the user into an infinite redirect loop.
Personally, I would recommend that non-hash links always load their content as expected, in a static manner. If the user then navigates, you may either end up with a URL like /about/clients#/ (if they went to the home page) (this shouldn't be an issue as crawlers will never end up visiting them this way) or you can have them redirect to / next time they navigate.
IMHO, I'd say that a pure JavaScript solution to the hash problem would be easier to manage as there are already many good examples of this.
Also consider using #! instead of # - this 'hash-bang' technique is being pushed by Google as a way of identifying to search engines that your hash is important and that its contents differ from what you would see without the hash part. Google can already point to specific parts of a page using # and if you follow the hash-bang technique on the client and server-side, it will be able to index your AJAX/Flash links just like regular links (see the implementation details and the requirements you need to fulfill).