... to strapping on explosive to the drone and piloting into something...
Have you looked at the "drone" in question? It's a $70, 12 inch wide, 6 minute runtime, 160 foot control distance, toy. A slingshot could move more weight further and probably more accurately.
... just to confirm, the answer is "b": The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
I updated his script to print the difference between the current POSIX timestamp and the value returned by the server. bing.com: current - server_value = 28800 reddit.com: 0 instragram.com: 0
Those were his three tests. I'm not surprised the Microsoft server is the one calculating a POSIX timestamp incorrectly. MS folks tend to do timestamp math very poorly. I suspect this only affects Microsoft servers, or horribly misconfigured $anything_else.
a) Something else in his php script is setting the TZ before doing that parse b) The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
Agreed. If the summary is to be believed, then it would be possible to: * use app to order up cash and show the QR code * take a pic of it with another phone (or screenshot and send it, or print it, etc) * have someone else go pick up that cash
That almost sounds convenient, but it also means anyone that can scan that QR code from any of the many cameras that are everywhere, could re-generate the QR code and go snag your cash. It would also be a way to steal cash from someone, whether by force or by using their phone while they're in the bathroom or something. No need for a pin... not a feature I want enabled for my account, thank you.
More importantly, the latest boards are UL certified. “Underwriters Laboratories” is an independent electronic safety certification so getting that UL stamp is a solid start for hovering confidence. Additionally, board makers have also been advertising their batteries as originating from Samsung or LG. So that’s something.
And here's one of the UL certified boards on their site: http://www.newegg.com/Product/... From the specs, it says, "Battery and Charger are UL & CE Certified"
It doesn't say the board is certified, but does that matter if the batter and charger *are* certified?
But this is not a case of user-clumsiness or stupidity. These things are bursting into flames during routine charging of their batteries when not in use. That makes them a defective product, and IMO crosses the line into the realm of regulation being appropriate.
And furthermore, when one bursts into flames, it tends to be while charging, which means it's *probably* in a house, which is *probably* in a neighborhood. That one fire is very likely to directly affect more people than just the owner of the board. So, to the GP's statement, I agree:
For me, things like this come down to the not-so-fine line between personal freedom and involuntary involvement in danger.
... and in this case, it seems there's a really good case to be made that these do pose unnecessary risk, to both life and property, to innocent bystanders.
I'd rather have an electric skateboard though (zboard, boosted, marbel, etc). Wish they weren't 3x's the price with 1/3rd the smarts.
There are plenty of reasons why one might be running Windows and (mostly) incapable of doing much about that, but the example you presented is not one of them (at least not in this context).
If the GP already runs Linux, and if they are truly sick of running Windows 10, then: * run GNU/Linux as the primary OS * stick Windows in a VM and only use it for apps that you can not replace for whatever reason * snapshot the VM prior to update cycles, so you can easily roll back.
That does still leave some edge cases where the user requires direct hardware access from Windows, but those are very rare cases, and the user is probably using something to image their test machine already anyway.
I really don't know the ins and outs on how fraud is prevented,...
Awesome.
So I really can't say they're dumb.
Nor can you say they're smart, since you (admittedly) have no idea what you're talking about.
it's just too big a big PITA to have to deal with all those small payments in cash.
This has NOTHING to do with the questions at hand. Contactless versus something-that-requires-contact-or-verification. Mag stripes would fulfill your requirements.
Skimming a contactless card via RFID can (more-or-less**) obtain all the same information they would get from swiping the mag stripe, but they don't need to touch your card. That is one of the larger problems with that setup.
Please note, this has little to do with NFC enabled phones. The majority (if not all) of those require some confirmation before they'll disclose anything (ex. swipe of your finger, pattern unlock, etc).
** for credit cards, I'm fairly certain this requires some bidirectional communication, thus the POS (point of sale) terminal in the summary. Other RFID devices require none of that, such as your license or passport.
Not as rare as a laptop with dual batteries but finding a laptop with space for two HDDs and a disc drive is still pretty friggin rare.
While I do have an older laptop with 2x 2.5" bays (and 3x mini pcie, dvrw, 1920x1080 screen), nowadays it's not too uncommon to find laptops with a 2.5" and room for a mini pcie (or m.2, or similar) SSD. I used a port labeled for a wifi module, and it works fine - YMMV. My only real point here is that the GP's 120gb SSD + 1tb HDD may be that sort of setup, and not necessary 2x 2.5" bays.
I still see it as either portable or secure, not both.
There are a million shades of grey between the absolutes. Phones are portable, and can be secure, as you noted (and in so far as a phone can be secure). Moving yourself between random 3rd party computers with who knows what running on them and checking your webmail from them... yeah, that's never going to be very secure. Moving between multiple devices you own... you can certainly use a local mail client, or a plugin, or a javascript implementation with zero knowledge encryption holding the private bits. Moving between devices you do not own, but aren't entirely untrustworthy (ex. a friends computer), it'll depend on the situation (maybe he has the plugin installed already and you're carrying your usb key with your private bits? maybe he creates a guest account on his computer for you? maybe you use the 100% javascript solution and the zero knowledge encryption to pull your key from an encrypted blob stored online somewhere?). There are option. And, maybe you consider the server-side s/mime implementation as another possibility. While partially compromising the security of your private key, it's still adding a significant amount of security and verification.
Your duality statement could easily be exaggerated to, "something is either online or secure, not both". You've gotta draw your lines somewhere, but there are multiple end-to-end email encryption solutions that will greatly improve the privacy and verification of email through webmail far more than the TLS work that the article mentions.
Alternatively (or in addition to that), Google could provide a javascript based solution. The private key storage would be an issue, but it could be held server side via zero knowledge encryption (ie. enter password on client side, get blob from gmail, decrypt client side). JS validation is also a solved problem, though it's ugly - basically, you just sign the javascript and then validate the signatures, but there is, of course, a bit more to it than that.
For almost all users on smart phones, they use a local client, and not webmail. Google could CERTAINLY implement S/MIME and pgp support there!
As of this moment, you can already do that with products such as R2Mail2 (https://play.google.com/store/apps/details?id=at.rundquadrat.android.r2mail2&hl=en).
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed). Personally, I find the need to encrypt email to be rare, but the need to verify the contents (sign) to be useful almost all the time. If the email is only signed, then you can still read all your email via webmail without a plugin. You can even verify the signatures without a plugin (with just javascript) because signatures do not rely on the recipients private key. You could also still send unsigned/unencrypted email, so a dumb webmail client is still useful.
All that said, the goal would be to make the feature ubiquitous. Google ships chrome, and could ship the "plugin" as part of chrome. Firefox could add a similar feature. Both could use the existing password/key storage that is already built into the browsers. For users that are taking their security VERY seriously, they'll be using a dedicated client, and probably won't be using gmail anyway.
You can have secure E-mail or portable E-mail but not both.
Sorry, but you are wrong.
All that said, it's obvious that gmail isn't the party we should look to for these features. They need to read the contents of your email in order to pay for the service (targeted ads support the service). Part of the business model is being able to read your email, so you can forget about keeping your email private from them based on any solution they provide.
I am surprised that they haven't attempted to implement s/mime or pgp with server-side private key storage. While that would significantly reduce the security of those technologies, it would also significantly increase the security and privacy for all those that currently use clear text email (and especially their webmail service), and it would provide interoperability with existing real email clients implementing the same standards (outlook, thunderbird, alpine/pine, mutt, mail.app).
There's nothing wrong with them improving the state of server-to-server and client-to-server transport layer encryption but, on its own, it does not provide sufficient protection for the examples they provided.
Use S/MIME, PGP, etc... All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed. For semi-important information, one should at least digitally sign the content to prove it wasn't modified in transit (ex. this should be used for any contracts, and if it's very sensitive, it should also be encrypted, and not just on the transport layer).
We may be reading into this too much. Maybe those who win more often are simply better at finding ways to achieve the goal of winning - including cheating. Something like taking a shortcut through a maze where a small corner is left open. If it's possible to cheat, maybe the game was designed with that in mind (ex. bluffing in poker, or bidding in spades, etc).
Again, "third party cookie" does not mean anything to most people. Granted, the checkbox is one clic away...
Why not go after the default browser setting then? Why not go after the sites that are using this feature (there is no technical reason why that like image or link have to do anything until the user clicks it, and the image can come from the originating site, preventing FB from getting a hit).
My whole point is, why is FB the target here? We have a very simple way to easily control and prevent this, and many other ways to further prevent such actions, and FB is not attempting to circumvent those means.
FB does not control pages using their "like" button. Hence, prompting to "click somewhere" to see the page won't work, ok?
The pages with existing like buttons would have to update the bit of code for said button on their site. They'll do that if they want to keep the feature, as FB can just disable or replace the existing like button. With an update, they can have the 3rd party site include a small bit of js to do the work (if no tracking cookie, display prompt to accept conditions). That is, if we don't hold the 3rd party sites responsible. Those sites are the ones that are delivering html that tells the client to automatically go and get external site data, and they're not informing the user that they'll be doing that.
Our complacency with allowing cross domain data is the root cause. Get rid of that, and all tracking and ads as we know them today will go away. It'll also break most sites these days, but that's part of the problem.
The only real advantage is ECC RAM support for Xeon processors...
And that's not strictly a Xeon thing. Go to ark.intel.com Click on any processor family. Click on Feature Filter. Clear the "Family" setting. Change "ECC Memory Supported" to "Yes", then click search. Observe Xeon's, Celeron's, Core i3, i5, and i7's, Pentium's, Quark SoC, and even Atom processors (ex. E3805 from Q4'14).
AMD also has extensive ECC support, but that's almost an entirely different topic.
Now... if someone could tell me what consumer level motherboard I can get for a reasonable cost that'll support ECC with an inexpensive late model Celeron that supports ECC, I'd love to know. I was recently looking at the Celeron G3920 (2.9GHz, Q4'14, HD graphics 510, 14nm process, ECC support, FCLG1151), and I *think* there are supermico's that will work with it, but I'm not really thrilled about having to spend server-level prices to support a $50 processor. AFAICT, AMD still has the low-end ZFS server setup crown.
Browsers can also be configured to aid with this. For example, the option "Block third-party cookies and site data", aka "from originating website only". I believe that used to be available for images as well.
Which is FAR too crude of a filter to be actually useful. Sometimes third party cookies are helpful. Most of the time they are not. A crude filter like that cannot determine the difference.
Please provide an example or two of "helpful" 3rd party cookies. I'm guessing the answer will be something along the lines of, "so that the 'like' button works on my foxnews.com articles", and that would also be wrong (that button does not need to be loaded from FB's servers and, when clicked, could do the deed that talks to FB).
Second, there is absolutely NO reason why the web page serving up the data cannot ask if the person requesting wants stuff from these third parties and to explain who and what these third parties are.
... and your browser can do just that if you like! It's not a site feature, it's a browser feature, and the reason it's not on by default is the same reason that the default firewall does not prompt you for every new SYN packet it sends. Feel free to enable that, or block 3rd party cookies. Expecting them to behave (be there and work when you want, but don't do bad things) is crazy.
Technically true is what we should be relying on for laws. For the cookies to work, they have to be under the facebook.com domain for facebook.com to pick them up. That's a 3rd party, and easily identifiable, domain, and easily blocked with a checkbox - which, arguably, should be the default behavior. If they use a bunch of domains, the cookie will be useless (it'd be a bunch of different and unassociated cookies).
Others have mentioned collusion between site operators trading backend logs that have nothing to do with anything facebook specific.... whether or not that's the true, that's not really the case at hand. I'm fine with saying that's dishonest, manipulative, illegal, whatever. However, in most cases, they're really straight forward.
The issue of scale has also been brought up, but scale doesn't really matter. Laws are laws. This will have other consequences to all other businesses, and facebook will simply find a way to make people click accept to see any part of the page, and people will click it. They should go after the root cause.
... But the implied reason for collecting a server log is to diagnose issues and compile aggregated site statistics, not to track individual users. And tracking cookies can get a lot more information than you can glean from your server logs.
Click the checkbox to "Block third-party cookies and site data". Done. It's sad that isn't the default, but who's fault is that? If one actually cares about their privacy online, they'll have done the bare minimum to protect it. There is no reason, as far as I can tell, to allow 3rd party cookies, except things like tracking, so add exceptions where you want to allow it.
I'm all for privacy, but if: * I'm running some site * someone (a bunch of people) embed an image on their page that hits back to my site (or a service I offer) * I log that shit cause those users are hitting my servers... why is it wrong for me to use that however data however I like?
IMO, if anyone should be dinged here, it's those sites that are embedding the trackers without notifying the user that they'll be sending the users browser off to umteen different external sites.
Browsers can also be configured to aid with this. For example, the option "Block third-party cookies and site data", aka "from originating website only". I believe that used to be available for images as well.
Users also have multiple options to control what the computer they own does online. For general browsing, solutions vary from browser plugins (AdBlock and friends), Proxy based solutions, hosts file modifications, local DNS server, firewalls, etc.
FWIW, I do NOT think sites should be encouraged to evade these options. As long as they're using their domains on all those tracking things (which, as far as I can tell, they are), then I don't see the blame falling on the service provider. Don't want them to get your hits? Block them (facebook/twitter/google/linkedin/etc), or don't use sites that do that to you. This level of legislation seems to go a step beyond the "don't post links that point to sites that host copyrighted works", which no one in their right mind agreed with.
What they did is akin to wanting to have a joy-stick instead of a steering wheel, but instead of just putting in an obvious joystick, they made it look just like a steering wheel.
... and it only moves 1" to the right or left and snaps back to center when you release. You hold it left and your wheels will keep turning more and more left - harder you hold, faster it turns. Let go, and it stays in that turned spot. That would be insane, and that's exactly what they did. Luckily, the gear change operation is generally done while stationary with the brake on, and only done at the start of driving once done, so accident counts are low and not severe.
I was curious about the Adobe Animate comment, so I looked it up. First of all, the provided link says no such thing. Second: http://blogs.adobe.com/animate...
...Flash Professional will be renamed Adobe Animate CC, starting with the next release in early 2016.
Animate CC will continue supporting Flash (SWF) and AIR formats as first-class citizens. In addition, it can output animations to virtually any format (including SVG), through its extensible architecture.
So it's the same exact thing as Flash Professional. It's just a rename, and they updated their software to also support HTML Canvas and WebGL and such as alternative output formats.
Slashdot Mirror
... to strapping on explosive to the drone and piloting into something ...
Have you looked at the "drone" in question?
It's a $70, 12 inch wide, 6 minute runtime, 160 foot control distance, toy.
A slingshot could move more weight further and probably more accurately.
I'm not referring to re-use or forgeries. I'm talking about theft.
... just to confirm, the answer is "b": The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
I updated his script to print the difference between the current POSIX timestamp and the value returned by the server.
bing.com: current - server_value = 28800
reddit.com: 0
instragram.com: 0
Those were his three tests. I'm not surprised the Microsoft server is the one calculating a POSIX timestamp incorrectly. MS folks tend to do timestamp math very poorly. I suspect this only affects Microsoft servers, or horribly misconfigured $anything_else.
Vote parent up.
The article the summary references is just a summary of this: http://jcarlosnorte.com/securi...
In which, he notes:
Offset Size Value Description
0 2 0x1f 0x8b Magic number to idenitfy gzip streams
2 1 Compression method
3 1 Flags
4 4 Compression Date
8 1 Compression flags
9 1 Operating system
He references that as coming from: http://www.forensicswiki.org/w...
But that document does not say "Compression Date". It actually says:
4 4 Last modification time. Contains a POSIX timestamp.
Even his proof of concept shows that he's parsing that field as a POSIX timestamp: https://github.com/jcarlosn/gz...
echo date('l jS \of F Y h:i:s A', $rdate);
It appears that either:
a) Something else in his php script is setting the TZ before doing that parse
b) The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
I do not recommend moving here, unless your hobbies consist of drinking and fornication, with a side of staring at a bleak and unforgiving desert.
Hrm... 2 out of 3 ain't bad.
Agreed. If the summary is to be believed, then it would be possible to:
* use app to order up cash and show the QR code
* take a pic of it with another phone (or screenshot and send it, or print it, etc)
* have someone else go pick up that cash
That almost sounds convenient, but it also means anyone that can scan that QR code from any of the many cameras that are everywhere, could re-generate the QR code and go snag your cash. It would also be a way to steal cash from someone, whether by force or by using their phone while they're in the bathroom or something. No need for a pin... not a feature I want enabled for my account, thank you.
http://blog.newegg.com/hoverbo...
Per newegg:
More importantly, the latest boards are UL certified. “Underwriters Laboratories” is an independent electronic safety certification so getting that UL stamp is a solid start for hovering confidence. Additionally, board makers have also been advertising their batteries as originating from Samsung or LG. So that’s something.
And here's one of the UL certified boards on their site:
http://www.newegg.com/Product/...
From the specs, it says, "Battery and Charger are UL & CE Certified"
It doesn't say the board is certified, but does that matter if the batter and charger *are* certified?
But this is not a case of user-clumsiness or stupidity. These things are bursting into flames during routine charging of their batteries when not in use. That makes them a defective product, and IMO crosses the line into the realm of regulation being appropriate.
And furthermore, when one bursts into flames, it tends to be while charging, which means it's *probably* in a house, which is *probably* in a neighborhood. That one fire is very likely to directly affect more people than just the owner of the board.
So, to the GP's statement, I agree:
For me, things like this come down to the not-so-fine line between personal freedom and involuntary involvement in danger.
... and in this case, it seems there's a really good case to be made that these do pose unnecessary risk, to both life and property, to innocent bystanders.
I'd rather have an electric skateboard though (zboard, boosted, marbel, etc). Wish they weren't 3x's the price with 1/3rd the smarts.
There are plenty of reasons why one might be running Windows and (mostly) incapable of doing much about that, but the example you presented is not one of them (at least not in this context).
If the GP already runs Linux, and if they are truly sick of running Windows 10, then:
* run GNU/Linux as the primary OS
* stick Windows in a VM and only use it for apps that you can not replace for whatever reason
* snapshot the VM prior to update cycles, so you can easily roll back.
That does still leave some edge cases where the user requires direct hardware access from Windows, but those are very rare cases, and the user is probably using something to image their test machine already anyway.
I really don't know the ins and outs on how fraud is prevented, ...
Awesome.
So I really can't say they're dumb.
Nor can you say they're smart, since you (admittedly) have no idea what you're talking about.
it's just too big a big PITA to have to deal with all those small payments in cash.
This has NOTHING to do with the questions at hand. Contactless versus something-that-requires-contact-or-verification. Mag stripes would fulfill your requirements.
Skimming a contactless card via RFID can (more-or-less**) obtain all the same information they would get from swiping the mag stripe, but they don't need to touch your card. That is one of the larger problems with that setup.
Please note, this has little to do with NFC enabled phones. The majority (if not all) of those require some confirmation before they'll disclose anything (ex. swipe of your finger, pattern unlock, etc).
** for credit cards, I'm fairly certain this requires some bidirectional communication, thus the POS (point of sale) terminal in the summary. Other RFID devices require none of that, such as your license or passport.
Not as rare as a laptop with dual batteries but finding a laptop with space for two HDDs and a disc drive is still pretty friggin rare.
While I do have an older laptop with 2x 2.5" bays (and 3x mini pcie, dvrw, 1920x1080 screen), nowadays it's not too uncommon to find laptops with a 2.5" and room for a mini pcie (or m.2, or similar) SSD. I used a port labeled for a wifi module, and it works fine - YMMV. My only real point here is that the GP's 120gb SSD + 1tb HDD may be that sort of setup, and not necessary 2x 2.5" bays.
I still see it as either portable or secure, not both.
There are a million shades of grey between the absolutes.
Phones are portable, and can be secure, as you noted (and in so far as a phone can be secure).
Moving yourself between random 3rd party computers with who knows what running on them and checking your webmail from them... yeah, that's never going to be very secure.
Moving between multiple devices you own... you can certainly use a local mail client, or a plugin, or a javascript implementation with zero knowledge encryption holding the private bits.
Moving between devices you do not own, but aren't entirely untrustworthy (ex. a friends computer), it'll depend on the situation (maybe he has the plugin installed already and you're carrying your usb key with your private bits? maybe he creates a guest account on his computer for you? maybe you use the 100% javascript solution and the zero knowledge encryption to pull your key from an encrypted blob stored online somewhere?). There are option.
And, maybe you consider the server-side s/mime implementation as another possibility. While partially compromising the security of your private key, it's still adding a significant amount of security and verification.
Your duality statement could easily be exaggerated to, "something is either online or secure, not both". You've gotta draw your lines somewhere, but there are multiple end-to-end email encryption solutions that will greatly improve the privacy and verification of email through webmail far more than the TLS work that the article mentions.
Great questions, and they all have answers already.
Webmail s/mime, pgp, gpg encryption: See https://www.mailvelope.com/, or https://www.penango.com/produc..., or similar products.
Alternatively (or in addition to that), Google could provide a javascript based solution. The private key storage would be an issue, but it could be held server side via zero knowledge encryption (ie. enter password on client side, get blob from gmail, decrypt client side). JS validation is also a solved problem, though it's ugly - basically, you just sign the javascript and then validate the signatures, but there is, of course, a bit more to it than that.
For almost all users on smart phones, they use a local client, and not webmail. Google could CERTAINLY implement S/MIME and pgp support there!
As of this moment, you can already do that with products such as R2Mail2 (https://play.google.com/store/apps/details?id=at.rundquadrat.android.r2mail2&hl=en).
You go the traditional install plugin route, but then web mail is no more portable than a fat client.
For this to be even partially true, you would have to assume that all received email is encrypted (rather than just signed).
Personally, I find the need to encrypt email to be rare, but the need to verify the contents (sign) to be useful almost all the time.
If the email is only signed, then you can still read all your email via webmail without a plugin. You can even verify the signatures without a plugin (with just javascript) because signatures do not rely on the recipients private key.
You could also still send unsigned/unencrypted email, so a dumb webmail client is still useful.
All that said, the goal would be to make the feature ubiquitous. Google ships chrome, and could ship the "plugin" as part of chrome. Firefox could add a similar feature. Both could use the existing password/key storage that is already built into the browsers. For users that are taking their security VERY seriously, they'll be using a dedicated client, and probably won't be using gmail anyway.
You can have secure E-mail or portable E-mail but not both.
Sorry, but you are wrong.
All that said, it's obvious that gmail isn't the party we should look to for these features. They need to read the contents of your email in order to pay for the service (targeted ads support the service). Part of the business model is being able to read your email, so you can forget about keeping your email private from them based on any solution they provide.
I am surprised that they haven't attempted to implement s/mime or pgp with server-side private key storage. While that would significantly reduce the security of those technologies, it would also significantly increase the security and privacy for all those that currently use clear text email (and especially their webmail service), and it would provide interoperability with existing real email clients implementing the same standards (outlook, thunderbird, alpine/pine, mutt, mail.app).
There's nothing wrong with them improving the state of server-to-server and client-to-server transport layer encryption but, on its own, it does not provide sufficient protection for the examples they provided.
Use S/MIME, PGP, etc...
All the transport level stuff isn't going to protect your email or ensure it's not modified in transit (or at the destination or origin).
Gmail's help on their new icon:
If you see the red padlock while composing a message
Don’t send confidential material, like tax forms or contracts, to that email address.
Fuck that... if you're sending confidential email without encrypting the content, you're already screwed.
For semi-important information, one should at least digitally sign the content to prove it wasn't modified in transit (ex. this should be used for any contracts, and if it's very sensitive, it should also be encrypted, and not just on the transport layer).
We may be reading into this too much.
Maybe those who win more often are simply better at finding ways to achieve the goal of winning - including cheating. Something like taking a shortcut through a maze where a small corner is left open. If it's possible to cheat, maybe the game was designed with that in mind (ex. bluffing in poker, or bidding in spades, etc).
Again, "third party cookie" does not mean anything to most people. Granted, the checkbox is one clic away ...
Why not go after the default browser setting then? Why not go after the sites that are using this feature (there is no technical reason why that like image or link have to do anything until the user clicks it, and the image can come from the originating site, preventing FB from getting a hit).
My whole point is, why is FB the target here? We have a very simple way to easily control and prevent this, and many other ways to further prevent such actions, and FB is not attempting to circumvent those means.
FB does not control pages using their "like" button. Hence, prompting to "click somewhere" to see the page won't work, ok?
The pages with existing like buttons would have to update the bit of code for said button on their site. They'll do that if they want to keep the feature, as FB can just disable or replace the existing like button. With an update, they can have the 3rd party site include a small bit of js to do the work (if no tracking cookie, display prompt to accept conditions). That is, if we don't hold the 3rd party sites responsible.
Those sites are the ones that are delivering html that tells the client to automatically go and get external site data, and they're not informing the user that they'll be doing that.
Our complacency with allowing cross domain data is the root cause. Get rid of that, and all tracking and ads as we know them today will go away. It'll also break most sites these days, but that's part of the problem.
The only real advantage is ECC RAM support for Xeon processors...
And that's not strictly a Xeon thing.
Go to ark.intel.com
Click on any processor family.
Click on Feature Filter.
Clear the "Family" setting. Change "ECC Memory Supported" to "Yes", then click search.
Observe Xeon's, Celeron's, Core i3, i5, and i7's, Pentium's, Quark SoC, and even Atom processors (ex. E3805 from Q4'14).
AMD also has extensive ECC support, but that's almost an entirely different topic.
Now... if someone could tell me what consumer level motherboard I can get for a reasonable cost that'll support ECC with an inexpensive late model Celeron that supports ECC, I'd love to know. I was recently looking at the Celeron G3920 (2.9GHz, Q4'14, HD graphics 510, 14nm process, ECC support, FCLG1151), and I *think* there are supermico's that will work with it, but I'm not really thrilled about having to spend server-level prices to support a $50 processor. AFAICT, AMD still has the low-end ZFS server setup crown.
Why log it? Why not block it instead, unless you want them to lift your stuff?
How do you differentiate the traffic from normal traffic?
The referrer header is a joke, and there is no other differentiation.
Browsers can also be configured to aid with this. For example, the option "Block third-party cookies and site data", aka "from originating website only". I believe that used to be available for images as well.
Which is FAR too crude of a filter to be actually useful. Sometimes third party cookies are helpful. Most of the time they are not. A crude filter like that cannot determine the difference.
Please provide an example or two of "helpful" 3rd party cookies.
I'm guessing the answer will be something along the lines of, "so that the 'like' button works on my foxnews.com articles", and that would also be wrong (that button does not need to be loaded from FB's servers and, when clicked, could do the deed that talks to FB).
Second, there is absolutely NO reason why the web page serving up the data cannot ask if the person requesting wants stuff from these third parties and to explain who and what these third parties are.
... and your browser can do just that if you like! It's not a site feature, it's a browser feature, and the reason it's not on by default is the same reason that the default firewall does not prompt you for every new SYN packet it sends. Feel free to enable that, or block 3rd party cookies. Expecting them to behave (be there and work when you want, but don't do bad things) is crazy.
Technically true is what we should be relying on for laws.
For the cookies to work, they have to be under the facebook.com domain for facebook.com to pick them up. That's a 3rd party, and easily identifiable, domain, and easily blocked with a checkbox - which, arguably, should be the default behavior. If they use a bunch of domains, the cookie will be useless (it'd be a bunch of different and unassociated cookies).
Others have mentioned collusion between site operators trading backend logs that have nothing to do with anything facebook specific.... whether or not that's the true, that's not really the case at hand. I'm fine with saying that's dishonest, manipulative, illegal, whatever. However, in most cases, they're really straight forward.
The issue of scale has also been brought up, but scale doesn't really matter. Laws are laws. This will have other consequences to all other businesses, and facebook will simply find a way to make people click accept to see any part of the page, and people will click it. They should go after the root cause.
... But the implied reason for collecting a server log is to diagnose issues and compile aggregated site statistics, not to track individual users. And tracking cookies can get a lot more information than you can glean from your server logs.
Click the checkbox to "Block third-party cookies and site data". Done.
It's sad that isn't the default, but who's fault is that? If one actually cares about their privacy online, they'll have done the bare minimum to protect it. There is no reason, as far as I can tell, to allow 3rd party cookies, except things like tracking, so add exceptions where you want to allow it.
Aren't there any devs left on this site?
I'm all for privacy, but if: ... why is it wrong for me to use that however data however I like?
* I'm running some site
* someone (a bunch of people) embed an image on their page that hits back to my site (or a service I offer)
* I log that shit cause those users are hitting my servers
IMO, if anyone should be dinged here, it's those sites that are embedding the trackers without notifying the user that they'll be sending the users browser off to umteen different external sites.
Browsers can also be configured to aid with this. For example, the option "Block third-party cookies and site data", aka "from originating website only". I believe that used to be available for images as well.
Users also have multiple options to control what the computer they own does online. For general browsing, solutions vary from browser plugins (AdBlock and friends), Proxy based solutions, hosts file modifications, local DNS server, firewalls, etc.
FWIW, I do NOT think sites should be encouraged to evade these options. As long as they're using their domains on all those tracking things (which, as far as I can tell, they are), then I don't see the blame falling on the service provider. Don't want them to get your hits? Block them (facebook/twitter/google/linkedin/etc), or don't use sites that do that to you. This level of legislation seems to go a step beyond the "don't post links that point to sites that host copyrighted works", which no one in their right mind agreed with.
Agreed, and continuing that line of thought...
What they did is akin to wanting to have a joy-stick instead of a steering wheel, but instead of just putting in an obvious joystick, they made it look just like a steering wheel.
... and it only moves 1" to the right or left and snaps back to center when you release. You hold it left and your wheels will keep turning more and more left - harder you hold, faster it turns. Let go, and it stays in that turned spot.
That would be insane, and that's exactly what they did. Luckily, the gear change operation is generally done while stationary with the brake on, and only done at the start of driving once done, so accident counts are low and not severe.
I was curious about the Adobe Animate comment, so I looked it up. First of all, the provided link says no such thing. Second:
http://blogs.adobe.com/animate...
...Flash Professional will be renamed Adobe Animate CC, starting with the next release in early 2016.
Animate CC will continue supporting Flash (SWF) and AIR formats as first-class citizens. In addition, it can output animations to virtually any format (including SVG), through its extensible architecture.
So it's the same exact thing as Flash Professional. It's just a rename, and they updated their software to also support HTML Canvas and WebGL and such as alternative output formats.