51–60 of 75 posts
Earlier quoted context omitted.
That's because our industry is full of hopelessly under qualified people who somehow manage to create software by randomly throwing together bits of code from stackoverflow / books and tweaking it until it "works".
You mean "hopelessly", right?
Earlier quoted context omitted.
As an example of the problem, see the "Issues and criticism" of the related topic "Link prefetching" in Wikipedia - https://en.wikipedia.org/wiki/Link_prefetching#Issues_and_cr... .
Almost all of those problems only apply to in-browser prefetchers, which reuse the user's session and connection.
It is the fucking internet, if you put something on there you should expect someone to find it, be it a crawler or an attacker. > 1. they are crawling potentially sensitive information granted by links with tokens If tokens in GET params are your security concept: please leave the entire field. 2. they are triggering potentially harmful and/or confusing actions in your website by repeating links So you built somethin…
You're correct, but there's no need to be a dick about it
Earlier quoted context omitted.
GET is only idempotent in theory. Way too many people abuse GET when creating websites.
Those people should suffer the consequences. I'm not a fan of facebook in the slightest, but they are crawling websites they were essentially invited to.
Using an analytics pixel is _not_ an invitation to crawl a website.
Earlier quoted context omitted.
Those people should suffer the consequences. I'm not a fan of facebook in the slightest, but they are crawling websites they were essentially invited to.
>websites they were essentially invited to Using an analytics pixel is _not_ an invitation to crawl a website.
It is the fucking internet, if you put something on there you should expect someone to find it, be it a crawler or an attacker. > 1. they are crawling potentially sensitive information granted by links with tokens If tokens in GET params are your security concept: please leave the entire field. 2. they are triggering potentially harmful and/or confusing actions in your website by repeating links So you built somethin…
Do you have a source for this? I Googled (!) and found this: https://www.stonetemple.com/google-chrome-discover-pages , which implies the opposite.
I don't use Chrome personally, but I do occasionally dump [none-too critical] preview files on open but otherwise 'hidden' urls on a domain for clients to view. I just find it easier for clients to deal with than inevitably lost passwords, etc, and tend to ask them to let me know when they're done so I can delete the folder.
I'd be interested to know whether their likely use of Chrome means that Google has a pattern of understanding of my domain space!
Earlier quoted context omitted.
> Actually as a service to your users don't put it anywhere where it doesn't add value. So don't put it anywhere.
I believe the tracking stuff comes with Like buttons and other Facebook widgets those are what I am referring to when I say "add value". But it could be argued that the tracking alone never adds value to the user.
Earlier quoted context omitted.
>websites they were essentially invited to Using an analytics pixel is _not_ an invitation to crawl a website.
No, merely posting it on a public server was the invitation
Making something available to the public is not the same as going to the google webmaster tools and telling them to index your page.
The summary of what most people are saying including some take aways:
- If you put something on the Internet it is public. Period. It is up to you to keep prying eyes away from that page. You can do that with strong mechanisms (like passwords and firewalls) or weak (like robots.txt) but you need to do something. You can't expect a page on the Internet to be private.
- Requests should never ever have anything sensitive in the query string. The query string is inherently logged. By your browser history, your web server, any tracking pixels like Facebook you put on the page, etc. If you absolutely must include a token in the URL (like with OAuth) make sure it is a temporary token and is immediately replaced with something more durable like a cookie or local storage, no unnecessary HTML is rendered, and the user is redirected to a new page that doesn't have it in the URL.
- GET requests should be idempotent. They should avoid changing any data as much as possible and should not have side effects. This is specified directly in the HTTP spec.
- If your page displayed sensitive data it should send the security tokens in a header field (like cookies or authentication). Users who hit the page without that header field should be responded to with a 404.
- Your point #3 is an add one. It is a bug on the Facebook side, yes, but it doesn't support your primary argument. In fact, if they fixed that bug it would make the perceived issues in your primary argument worse.
- Re #4 they don't need to warn you. See the first bullet. If it is on the internet it is public. Skype, Slack, Twitter, Google, all do the same thing.