Note that everything you talk about is only the RFID part of NFC. NFC actually includes two entire categories of communication technologies, operating on two different frequencies. The more interesting (IMO) part of NFC is the embodiment of the contactless smart card technologies, which enable two-way conversations between a pair of intelligent endpoints, not merely reading and writing of different data formats.
I simplified things yes, although without mentioning it I did (unintentionally) mention both.
HID 26-bit tends to be a one-way "read-only" option like in RFID. NTAG is a two way option able to store data on the card/tag, which is actually the main reason I use it over HID. The smartcard options are of course two-way but generally with even more features (challenge response being the biggie)
Clearly doorway entry doesn't have too much use for the writable aspect, but other uses plus the whole learning aspect lead me down that route, and after having 200+ tags on hand it just made since to use them on the doors too.
Even the simple flash memory aspect of NTAG is interesting in some of the uses I've seen. NTAG 216 has 888 bytes of flash you can use, and all of the NTAG 2xx's lay these out in 8 byte "chunks" Each chunk has its own flash write circuit in the silicon, aka a "security bit", basically a fuse you can blow after which that 8-byte chunk is no longer writable. You can also query this fuses state. or even go the long route by trying to write to it and checking if the data changed, before treating the tag as valid.
Of course the smart card features available to NFC are as you say very interesting. Being able to send a challenge to be used with a private key, without any access to the private key, has been a problem since the start of asymmetric ciphers, and even a decade+ ago was only solved by specialized (and expensive!) HSM devices.
Hell, the NXP SmartMX brand tags not only have factory programed smart card functions but on-board random number generators, which are only a bit over $5 usd each in small batches. Not the greatest pricing in NFC, but pretty good in my book for just messing around with at home.
It's probably worth noting that quite a few different frequencies are used at the radio level.
At work we use 13.56 mhz RFID tags for some internal inventory counting, with receiver units in the ceiling that can poll almost 200 tags per second in one broadcast. NTAG uses this same frequency.
But HID 26-bit tends to be in the lower 125 khz frequency. There are others in the UHF range.
I guess it's more like a layer-1 vs layer-4 OSI difference there. Communications vs data formats.
In the hotel comment at the end of my last post, I know of at least one chain that uses Indala brand cards, a proprietary format to serve a similar purpose to HID 26-bit. The difference is Indala comes with the "facility" ID part burnt in from the factory, and must be specified when ordering and can't be changed afterwards. You're stuck ordering from them forever. HID 26-bit also provides for separate facility/unique parts of the ID, but both are user writable. Pretty sure it has 24 bits for data, 2 bits for parity one for each "half", but if I recall correctly it specified an 8/16 bit division for those purposes. And of course one can use those bits anyway you want, though obviously to keep compatibility with other systems you'll certainly want to assume the right 16 bits for the unique ID part.
Wow, C drive, I almost forgot about that. I hope that does not trigger any other ancient, painful memories. How is life, back there in Hell?
Hey now, CP/M and CMS wasn't that bad! It was a perfectly acceptable OS for your 80's multi-architecture and single user needs.
Of course it is strange parent poster didn't use the SSD to replace their A: hard drive. Gotta really wonder what SSD is being made that is smaller than the C: floppy disk used originally. Especially seeing as they only replaced the second floppy drive!
Any that have NFC-capable door locks. I doubt there are many (if any) of those, though, because until this update only Android phones could operate them. Hotels have used Bluetooth for their digital key systems, because it would work with all mobile devices. Not that iPhones are catching up, maybe we'll see hotels switching to NFC.
Personally I was hoping for protocol details, as the question you replied to depends fully on that.
Saying "NFC" is a lot like just saying "barcode" or "magstripe" There are proverbially hundreds of data encoding standards within each of those, which actually even Android has limitations on regarding its NFC chip too.
For example I use "NTAG" NFC at home, and Android supports the NTAG 215 spec but not* 216 I use. There's also an NTAG 213 spec but I don't use that or know if Android supports it. Being older I'd assume so but never checked. *(That's not to say there aren't options, just none "baked in" and easily accessible to apps, or even most users)
As NTAG was made by NXP and not HID, I'm not much expecting Apple to get that one either. HID is by far the largest provider of RFID and NFC gear.
The HID 26-bit standard is probably the most widely used, as HID Global has essentially allowed its use by anyone for most anything. It's not quite the "open source" of the NFC world, but might be better described as "open licensed freeware".
So while Android's NFC supports more NFC protocols to userland than Apple, and for much longer now, one must in general still be careful throwing out the "all" word. Even specifically regarding hotels, some got jiped on early proprietary systems that specifically go out of their way to create vendor lock-in, and those poor ignorant souls will very likely not be compatible still.
It would be acceptable to require a desktop computer as an intermediary, but it must be my software that runs on the desktop, not some magical program from who knows what. Is this possible? (I don't think so, but I'd like to be proven wrong.) And don't tell me to just use the AppStore. My application does not meet Apple requirements (it provides for in-app software upgrades).
Check out the "iPhone Configuration Utility" published by Apple (there are win/osx versions)
Since iOS 8 it lets one "side load" an.ipa or an.app bundle to an iPhone. The former intended mostly for corporations to distribute "enterprise licensed" apps to their fleet of devices, and the latter intended mostly for developers, so with your particular use case falling somewhere in the middle of those it's hard to say if it will be ideal for you.
I use it for provisioning devices at work. Each "profile" you create can be applied to a connected phone, can be remote pushed on pre-registered cells, and generates ".mobileconfig" files that can be delivered to a device via web download, email attachment, etc.
One word of warning, devices not under your own control are going to prompt the user to trust your.mobileconfig certificate and key when being installed by them. The best I can describe how it looks would be similar to accepting a self-signed https certificate in a browser (before chrome started hiding that ability at least)
Also your app won't have access to any of the AppStore hooks for analytics. If your app doesn't "phone home" (which users tend to hate), you won't even know someone installed it this way. Being that you specified a closed source program and purchasing from you, it implies to me there may be piracy concerns with this. Not having ever pirated apps, or made apps to be pirated, I can't really expand on how easy or not this is or what can be done on your side, but I figured you'd want to be aware of that.
Also on the end-user trust subject, when you run the config util you'll see a bunch of categories of things the tool can change, similar to windows group policies pushed out to desktops. But be aware that each category you have setup in your.mobileconfig file will be listed out when the user is prompted to accept and trust your cert.
So don't go thinking you can setup an app install profile along with a "secret" web browser proxy setting profile, to try and trick people into thinking it is just to install your program. They will be informed of the fact a web browser setting profile is there too. This tool lets you modify most any setting available to the user, and plenty of settings that are hidden (like cellular carrier profiles), so requires a huge amount of trust from the one making those.mobileconfigs. If that trust is abused, you'll likely be labeled a malware pusher, evil hacker, or worse.
I'm not implying anything about you personally here, just throwing that out there. Android users are used to this sort of permissions abuse and simply avoid you on the play store without complaining much. Apple users tend to bitch about such things loudly to anyone that will listen. Including reporting such behavior to Apple, which isn't likely to help your "can't get app approved" situation any.
Why wouldn't you be happy to see this in a court of law that examines whether the officer's response was appropriate or not? That's all I'm asking for.
Then perhaps you should have said that instead of saying the exact opposite of that to me.
You said you blame him, the officer. Out right blame him with no court of law, no judging the response, and even misrepresenting the very basis on if it could be appropriate or not.
You explicitly claimed he had no justification, despite a 911 call recording you could have listened to that gives that very justification, and despite the twitter posts showing this was a swatting which makes that justification based on false facts. You can't have a true or false justification when you outright try to claim there isn't one in the first place.
You explicitly claimed there was nothing to react to, despite the video clearly showing action. You didn't bother raising any points on if that action justified any reaction at all let alone the one that happened. You outright denied any action having happened.
You are very clearly prejudging the situation and stating it is for reasons other than those presented.
This is not you asking for it to be seen in a court, this is you placing blame.
As for why I myself wouldn't be happy to see the outcome of the court case? Well I guess I wouldn't be happy because I would be happy to see that.
The post of mine you replied to specifically said I didn't blame the victim, and find it hard to blame the cop from what's been released so far. Elsewhere in this thread which you likely haven't seen, the only blame I lay is on the stupid kid that self-incriminated himself requesting the swat in the first place, and for the potential mystery 3rd kid making the call to 911 for him (assuming that person exists and isn't the same kid)
I'm still not sure what to think of the 1st kid, the one that gave the fake address and egged the others on...
I am. I'd prosecute the cunt for murder, because he just shot an unarmed man with no warning and with no justification.
"Justification" as in being told the person you are being sent to has a weapon, has already killed one person, is holding three others hostage, and has stated to the 911 operator "If you send anyone out I am definitely not putting my gun down"?
"No warning" as in seeing the person described above raise his arm quickly to point straight it at you with a clenched fist?
I think it's pretty hypocritical of you to blame someone for believing exactly what you would believe in the same situation.
I also think it's pretty dishonest of you to say you would in no way have reacted the same either. Especially with people like yourself that would then blame you for being directly responsible for murdering one or more of your fellow officers by not stopping the shooter.
If you really wish to ignore all the evidence and blame people anyway, I guess that's your call, but don't expect others to not think less of you for it.
Whoever made the call, as well as the officers who couldn't be bothered to Not shoot someone.
And this should be trivial.
The stupid kid that requested the swatting call posted on his twitter account "That house I had swatted is on the news" The other stupid kid he was arguing with also posted screenshots of his direct message with the first stupid kid, providing the address as his own and telling him to come try something.
Twitter should have all of that logged along with their home or cell IPs, which would lead back to a name on an ISP account with an address.
Their gamer tags were also used and shown, which should similarly point to connection logs with IPs.
Only the 3rd stupid kid who actually placed the 911 call himself may possibly have not left a call or voip trail. But seeing as this will be a murder charge, and they will soon if not already have in custody the kid requesting the swatting, I highly doubt that kid won't drop the swatters name and info if for no other reason than hoping he gets a less harsh sentence.
You know nothing will happen regarding the cop though.
We know something. If he had done something obviously threatening, the police would be shouting it from the rooftops and releasing all their bodycam footage to provide justification.
When they clam up and give only the fewest details possible, you know they have no excuses.
The body cam video is at the top of the page of the very first link in the summary...
Unless the guy answered the door shouting he was going to kill the cops, or unless he was holding a firearm as he opened the door....
I'm really unsure about that one.
You don't usually wait for the person to finish raising their weapon, train it squarely on you, and open fire, all before you react to defend yourself.
In the half a second or less that it took for the victim to very quickly raise his arm from a downward position to a pointed directly at you position, at that point you have less than a fraction of a second for a trigger to be pulled.
As you can see from the video, the victim raised his arm Very fast to get it to a straight outward pointing at the police position, all in less than half a second.
If the person DID have a gun, then at that moment you have far less than a half of a second of time to react before a trigger is pulled. His fist was clenched as well.
The only way to know for sure at that point that he in fact did not have a gun would be to wait for the shot to not happen, and then wait even longer for him to continue raising his arm upwards (at a slower rate for some reason)
Personally I would have most likely thought the same thing, although it would have been more "I am about to be shot and killed" as I wouldn't have had a weapon on me or trained at the guy to prevent it.
To be clear, I'm not blaming the victim for "putting his hands up" wrong. What I'm doing is not blaming the officer for believing in that half of a second the person was about to open fire, nor blame the officer for not waiting the tenth of a second or less to hear and see someone get shot or not.
The entire situation was fucked up for everyone that was in it to be in, and even more fucked up after taking into account what caused the situation in the first place.
You are making an assumption on the situation. What we know is that as far as the police knew they were rolling on a murder and hostage situation (hostage in danger of murder as well). We don't know if the potential hostage taker had his hands hidden, whether he made any sharp movements - basically we know nothing. We don't know if the officer followed procedure, or what he was responding to. To say that they just rolled up and shot the first person they saw is only showing your bias and not what was reported.
This is untrue.
The police have released the 911 call audio, a dash camera video, and the body camera video from the police officer who made the shot.
All of this is linked in the article above, specifically the kansas.com news URL. You can see all of the things you claim "we" don't know.
You can see the victim raising his hands, but then turning sideways and making a stance with his legs that one might do if they are about to angle a weapon on someone. At that moment one of his hands was, from the side view, in the back and not visible.
It does look like, in hindsight, he was attempting to appear unarmed and likely succeeded in doing so for the police that saw him open the door when he was standing face-on. By the time he was standing sideways however, any officer who just arrived not seeing before this point, including the one who fired, would only see what looks like an intentionally hidden hand being moved in an action one would do if they had a weapon and was about to raise it.
With the fact the shooting officer only had partial information being witnessed, and that partial information does very clearly look like the victim has a weapon, I can't fault that officer for his actions.
Only once you see the footage before that point do you clearly see he is unarmed. And it's worth noting that all of the officers that were present at that point in time did not open fire, so clearly interpreted what they saw correctly.
You can also play the 911 call audio to answer your question "we" have about what they were responding to.
In Vietnam they fight wrongful views, we're fighting fake news, can someone tell me what the difference is?
Fake news is: "Nguyen Trong Nghia took his trash out to the street last night at 4PM in pink bunny slippers"
I know that is fake because I just made it up. Even if I'm accidentally right, I intended it to be a comical lie, so it should probably count.
Wrongful view would be: "Nguyen Trong Nghia took his trash out to the street last night at 4PM in pink bunny slippers"
Where Nguyen claims he did not and does not take out his trash, despite a video I recorded of him doing so in his pink bunny slippers that I posted to Youtube. Nguyen then has the video taken down and tells his military to kill me so I stop talking about his slippers.
Or at least it would be if I had such a video to post and he cared who I was and any of that above had happened. Which it didn't, but it makes me happy imagining it did:P
As an upside, I wonder how many people will now be picturing this higher up political head taking out his trash wearing pink bunny slippers? I hope it's at least a couple.
He did not seem to have hurt anyone, but only threatened them (with gun violence too). And he got 3 years worth of meals on the tax payers dime. Mission accomplished?
Even there he failed at being efficient at the task.
He could have just wrote to the parole board the first time that he hates humanity and wants let out early to get a head start on making everyone pay.
Then he wouldn't have had this period of unemployment to solve, all while still seeming like the go-getter he claims to be!
BGP vs. Root name servers? I don't know the relationship (if any) between the two, but is it just coincidence this is happening less than a month after this:
No direct relationship, other than DNS servers like all servers have an IP address, and the backbone routers need to know how to get your traffic to said IP. BGP is how the backbone knows where to send packets to get to the destination.
Normally if you try to go to say Googles web server, the BGP tables list Googles IP space and point to the backbone routers that directly connect (peer) with Googles routers.
In cases of hijacking like this, Russia updated those route tables to say Google is directly connected to one of their own routers, so any packets you send to a Google IP end up going to Russia first. Then they can do whatever they want, like record it and then pass the packets back to the routers originally listed in BGP before the hijack.
Root DNS servers would be similar, although there are many root DNS servers around the world and any lookups you make tend to semi-randomly pick one from the list for each query.
Another quirk with the root servers is how they are distributed and that they use a logical/physical separation, primarily to be extremely efficient but it can help in cases like this too. There are 13 "logical" root servers, named with the letters A to M, each for the most part under the control of a different organization/entity. However for any one of those logical names, there can be many physical servers that answer for it. They also don't use unicast IP addressing like nearly every server you're used to, but a type of addressing called anycast.
So for example, the "A" server is run by Verisign (from back when they were Internic), and the "E" server is run by NASA. But "A" actually points to many physical servers distributed around the US.
Anycast provides one IP for each of those many separated servers, and that IP is actually answered by many different networks and ISPs, each having many redundant physical servers to distribute the load over. Which cluster of servers you get mainly depends on which of those networks is closest to you on the network. So you querying the anycast IP on the west coast will have completely different networks and servers responding than if I queried that same IP on the east cost.
That makes it pretty difficult to hijack in a useful way, and to hijack enough of those routes and servers in a physical area on a single anycast IP, let alone more than one of the server clusters, and let alone again more than one "letter" designated root.
If instead of a USB stick one used something easily readable by a smart phone, the verification part could likely be fully streamlined and automated. There are plenty of places online you can feed in a wallet hash to query the balance from the blockchain.
I'm just not sure what hardware would be suitable.
Programmable NFC tags I've used hold anywhere from a few bytes up to a couple kb, which wouldn't be enough.
Even things like QR or blot codes weren't really intended to hold a hundred or more KB, not to mention that would be one heck of a QR code!
I suppose for smartphones that support OTG/USB, going with a flash drive would be OK, but it's a bit clunky still.
But scan the root of the removable drive for wallet.dat, verify the checksum, get the hash, and submit to some of those balance checking services. Some basic sanity checking on differing results to show a warning or something would also be useful.
There's got to be a better type of hardware that functions as block storage and can be used with a USB interface and something else more fitting for a mobile to talk to...
Most of that is simply false, and I have proven it myself with HP Compaq, EliteDesk, and EliteBook hardware.
You don't need access inside a network or on the physical machine, it has been proven to "call home" and receive orders much as botnets do, over unblocked HTTP requests.
Etherial shows nothing except ARP traffic while powered off, or powered on in any mode but provisioning mode. In provisioning mode Etherial shows two TCP connections to my provisioning server, and neither are HTTP.
You can't stop it if it is plugged into a network
Until ME is enabled, it doesn't even perform ARP requests let alone is capable or tries to send packets anywhere.
and all of the benefits you listed already existed in other forms which didn't require a massive multi-million-dollar engineering effort to stick inside the chip undetected for years.
It was never hidden in the chip, you just didn't bother reading Intels documentation, which was publicly available on Intels website since before vPro and ME hit the market.
Yes management cards were available before, but they are equally closed source and not auditable, and cost extra per PC to deploy.
If it were legitimate it would have been public knowledge from the start,
Documentation goes back to 2008 when vPro, the software containing ME, was released.
not a secret projects the alphabet agencies recruited hardware developers for, required top secret clearance to undertake within the Intel team working on it, etc.
Any evidence for that claim? Other than Intels own website and documentation that disproves it was "secret"?
The justifications for the existence of it are like the shills
Oh, damn, wish I saw that sooner before actually providing you with facts you don't care about. Yes, I use technology, that makes me a shill by your definition. Continue on with your fantasies, I'll stop ruining them.
Well, that's fucking scary. What is the alleged upside to Intel ME? Asking for a friend...
Mass configuration, deployment, and recovery for a large fleet of desktop computers you are tasks with managing.
You enable ME to remotely control the hardware and provision its boot drive, and manage the initial setup of the OS down for untrained staff for repair purposes.
You can enable it by hitting Control-P at boot, turn ME on, setup an IP/vlan, and upload a public key into it to authenticate. Alternately you can load some config files on a USB stick to do that, and hitting Control-P will see this and use those configs for you. Alternately again, if you buy a hundred or more PCs a year, you can provide a special public key and ME-Manager IP address to your OEM, and they put it into a special provisioning mode with that info. On first boot it will contact your provisioning server and accept configurations sighed with that special keypairs private key, and the provisioning server then uploads the real public key and other settings.
Once provisioned, you can instruct the system to mount an ISO image over the network to be in the optical drives place, and send power on/off events. Generally you'll do this to load your initial OS base image and let it image the HD for your company. Once that part completes, the base image OS does its own initial setup depending on OS (Active directory for windows; ldap with puppet for unix or RedHats launchpad as just two examples)
When a desktop has a boot drive failure, you can order a new HD and have it shipped to the branch office, and have nearly anyone swap the HD out. In the mean time you've reset the system to be in provisioning mode, so you instruct your "remote hands" to change out the HD for the new one and hit the power button. The system comes up and has the HD imaged again, either with a previous backup, or your base image, and go from there.
The concept is a great one.
However the GP is telling the truth when they say the ME code can't be audited. That's a pretty big problem as you have to trust Intel that it does what they say it does.
Of course to even get to ME, you need either layer-3 network access or physical access. If one has physical access they already "own" the system, and already falls under physical security instead. It's the local LAN access that can be a problem.
The concern in the real world isn't so much about Intel or the government, as those bodies already don't have access into our firewalls nor do we provide them VPN access in. It's about other employees which need to be in the building to do their work and thus have access to the LAN.
GP also intentionally confused the separate issues with taking over the ME code. Researchers have found code exploits and used those to perform the hijacking of the ME. There is zero evidence Intel has any additional access than is claimed.
This is like saying a one-off typo in some code that results in a remote exploit in your webserver is the exact same thing as the makers of that webserver intentionally granting someone else access to your system. And that is rarely the case.
As the ME code isn't able to be audited the possibility is not zero percent. But even if it could be shown Intels code has no backdoors and everything is written to work exactly like the ME documentation says it does, that only means Intel is trustworthy in their intentions. Bugs in code that result in an exploit are still very possible and still a real threat.
I just don't see the usefulness of saying "Looks like a bug in OpenSSH has an exploit, and Linus allowed it to be put on Linux, thusly I will never trust another thing Linus says or writes including any patches to fix the problem" purely due to not being smart enough to understand the math and code doing encryption.
You misunderstand it's just broadcasted to all cells assuming your phone might be on and listening.
Actually I believe you are partially misunderstanding, and parent is correct.
From grandparent: Your phone could listen for its ID and receive text messages without revealing it's location. Making calls or sending messages would however reveal your location to your carrier.
The existing cellular network does not work via broadcasting messages to all towers such that your phone could passively listen for it. Your phone registers with the cell tower, which updates the carriers internal routing info, and only then does the network forward things for your cell ID to that one tower you last registered with.
If your phone unregistered, the network will either hold the message or simply reject it as undeliverable. If your phone registered to a tower and then simply "goes dark" without unregistering, the message will still go to just the last tower you registered with for a little bit to be broadcast there. The tower will retry a number of times until it receives an acknowledgement from your phone, and failing to do so (with the phone not transmitting) typically results in the message being rejected back or simply dropped. After a few minutes of the phone being dark and not responding to the towers (think like a constant ping check), the route gets removed from the network as stale, and then even that one tower no longer transmits anything to your cell.
To have a cell network operate on a true broadcast without acknowledgement type of basis, it would need redesigned from the protocol up. This would be much closer to "possible" on a home-grown newly designed cellular network/protocol, such as this article is about.
But the bold part of the quote above indicates GP was specifically talking about your carriers cell network, not a newly made one that works in a different way such as this.
I'm also wondering how this person is routing their trips to avoid superchargers.
I live in a fairly sizable city with over a two million population count.
We currently have one supercharger fairly far south. I live on the south west part of town and that supercharger is still a 15 minute drive from me away from the city center.
We do have one more scheduled to be built on the far north side, but won't be completed until the end of 2018. I work roughly in the middle west or as many say slightly into the north west. The planned supercharger would be 20 or so minutes away (actually closer to 35-40 in rush hour traffic) from work and in the opposite direction from my home.
So the only special routing I need to do to avoid superchargers is to basically drive anywhere whatsoever except in one direction out on one of 8 highways.
Now there are other non supercharger stations around, and not nearly as out of the way. But at least a few months ago last I checked, on my route home to work, there were zero public charging stations. For fairness that would be compared to 3 gas stations along the two routes I can take.
My typical weekly grocery shopping routes would take be by more non superchargers and regular gas stations as well. And there are enough around town that any non-typical route I may take to get to some specific place would probably be fine. In fact I seriously doubt I would need to charge up while out running around so long as I leave home on a full charge.
Please note I'm not trying to frame this as any sort of problem for me. Personally supercharge stations wouldn't likely even come into play for me unless I'm taking a trip outside of the city. Most of my charging would need to be done at home only, and with my normal driving routines that would be more than enough for my home-to-work route and my home-to-shopping routes.
But my point is you don't need to do any special work to "avoid" superchargers, it just naturally happens when you don't do special work to seek them out.
Why do they need to shout "Hey, here are all the access points that I have connected to in the past"?
It's part of the spec, not so much wifi specifically but DHCP and DNA protocols.
The idea was when you first connect to a wifi network, you use ARP at layer 2 and broadcast a DHCP request to get a valid IP to begin using layer 3. When you are disconnected "briefly" and reconnect later, that IP is likely to still be valid for use.
Using DNA (direct network attachment), you can broadcast the previously used router MAC, device MAC, and SSID to verify you are on the same local link, and can begin reusing your previous IP without having to wait for a DHCP renewal. If you send an ARP with the remembered MACs, and get a reply, something else is now on the IP you had and you must renew with DHCP to get another IP. If you don't get a reply, its generally safe to assume it.
I presume it was assumed this would be a common and desired situation. Walking around in and out of wifi range, or maybe allowing the radio to go into a sleep mode where it basically is off and thus detached from the network, this does let you reconnect a bit faster.
I also presume the security implications were just not thought of or cared about.
Is this how it works? My understanding that tracking cookies will be a) multi-domain and b) will also include add network domain. For example, Taboola cookie would be still accessible across all sites that use Taboola. Is this not the case?
That is the case in IE, but in all other browsers no, a cookie can only be set for a domain if sent by a server on that domain.
But look at slashdot as an example. When you go to slashdot.org, you are loading content from 4 separate host/domains.
slashdot.org can set a cookie that gets sent back to slashdot.org But you are also loading content from other domains: a.fsdn.com content is loaded and can set a cookie, which gets sent back to a.fsdn.com gstatic.com content is loaded and can set a cookie, which gets sent back to gstatic.com etc
If you went to another website owned by FSDN but isn't slashdot, odds are that site will also load content from a.fsdn.com and thus that domains cookie will be sent back to a.fsdn.com again.
In this way a.fsdn.com can track you over all of the websites that load its content in, be it slashdot or freshmeat or whatever.
Now add in the fact that most websites these days load content from the google ad network, or facebook, or twitter. Each of those sites can set a cookie on their content and it gets sent back when visiting any other website that also loads content from them.
This is how facebook and such track you over most of the Internet, even if you never do or have visited facebook.com directly. It's almost guaranteed however that you have loaded content from facebook.com indirectly, and your browser happily sends the facebook cookies back to facebook.
What this feature does is tag a cookie not just with the domain of the sending web server, but also with the domain in your address bar.
That means the facebook cookie as loaded from slashdot is stored separately from the facebook cookie from random-other-site. Revisiting slashdot will only send the facebook cookie set with the slashdot domain, not the facebook cookie set by the random-other-site domain.
A nice set of standards guidelines being published by an official body for how and when numbers get whitelisted would be very useful too.
I don't think it should cost any extra to do this on top of the existing service costs, but actually performing good verification and forcing carriers to allow a means to do that would go very far.
Our voip system I manage at work is one of those that technically "spoofs" caller ID, however only using DIDs we have registered. Not all of our phones have public DIDs, we call them "Internal Only phones", however those extensions always present our reception desk / main number in caller ID, so it is at least possible to route an incoming call back into the building, even if that routing is done manually by a human.
However we also have three separate SIP trunk providers for outbound calls, and only one of those routes DIDs in to us. We have another forth SIP provider for the other half of our incoming DIDs, and due to their pricing we don't use them for outbound at all.
Currently those outbound only providers have no method to verify our DIDs belong to us, since they don't have access to the registries of the inbound providers who publish those DIDs. This needs fixed way further up in the chain.
Also another reason for the guidelines mentioned above is because we would in essence need to whitelist two blocks of DIDs (1499 numbers in total, don't ask) with all 4 service providers, and again 2 of those 4 have no idea what our DIDs are and no way to verify them.
It would truly suck for each provider to have their own little, and different, white list process. So long as the rules to white list are all the same, we would know any changes accepted by one would be accepted by all of them.
This is also part of why a white list fee per number isn't particularly reasonable. I'd be going through that process four separate times, multiplied by basically 1500 numbers would be 6000 line-item style charges. Even at one dollar that is an annoying thing to deal with, but multiplied by whatever dollar amount you had in mind could easily push it into the realm of ridiculous.
Much more reasonable would be to charge a set amount per verification process. For the vast majority of us with larger blocks of numbers, this would be a one-time process when starting service, and likely not have to change for years. Obviously for whichever service is actually routing newly requested DIDs to you that they serve out of their pool, no verification is needed simply because they already know. If I'm purchasing another 200 DIDs from provider A, it will be A that assigns them to us and should count as verified. Only providers B and so on would need to do any extra work for that.
This way it would push the burden onto those companies that are frequently changing their DIDs and numbers around often, which at first glance are the very companies causing these problems in the first place.
Care to explain how this story has anything to do with copyright in general or Steam in particular?
Dunno what he is referring to about Steam, but as far as copyright goes this story (and millions more) are quite relative to copyright protection and theft from us the public.
In order to get copyright protection, that protection comes with a cost.
Problem #1 is that now our Government forces copyright, and paying that cost, on everyone by default. This shouldn't be.
But the cost that is required to pay in exchange for that copyright protection, is that after a limited time that copyright ends and the public gets the right to do anything with the work they want.
Problem #2 is that "limited time" is now a hundred years after the author dies, which arguably isn't all that limited. But:
Problem #3 is that even after the insanely huge time given as "limited", that cost is still expected to be paid in exchange for giving you that copyright protection. Again that cost is that the public gains the right to do anything they want with that work.
Companies locking up their work behind encryption, and/or keeping a portion of that work on their own servers, completely negates the possibility for that cost to be paid. They are intentionally trying to prevent the payment to the public they owe for the copyright protection they are stealing for free.
This is no different from me intentionally writing you a bad check to pay you for that car you are selling. And not just intentionally writing a bad check that you are unaware of the fact it is bad, but hand drawing a check picture on a napkin signed with a drawing of a middle finger made out for $0, so you KNOW beyond any shadow of a doubt I have no intent on paying you the asking price of that car. Except the government will force you to still give me that car, basically for free.
Holding parts of the software back intentionally so it won't function, so it can not be given to the public as the payment for copyright protection requires, is no less fraud than the check example above.
Now, what would you do in the above example if I handed you such an obviously fake check you realized wouldn't be good, and literally all of my actions state I refuse to pay you? You wouldn't give me that car for free, would you?
This is what is meant by we should no longer be even entertaining the idea of granting copyright protection to such companies.
Except if I don't respect the copyright protection they are stealing from us for free and without payment, WE get punished. IE if you didn't give me that car for free in exchange for my silly money check made out to "fuck you", the government would forcibly take that car from you to give to me.
How fair is that? It isn't. And that is the root of the complaint about copyright law as it currently stands.
Slashdot Mirror
Note that everything you talk about is only the RFID part of NFC. NFC actually includes two entire categories of communication technologies, operating on two different frequencies. The more interesting (IMO) part of NFC is the embodiment of the contactless smart card technologies, which enable two-way conversations between a pair of intelligent endpoints, not merely reading and writing of different data formats.
I simplified things yes, although without mentioning it I did (unintentionally) mention both.
HID 26-bit tends to be a one-way "read-only" option like in RFID.
NTAG is a two way option able to store data on the card/tag, which is actually the main reason I use it over HID.
The smartcard options are of course two-way but generally with even more features (challenge response being the biggie)
Clearly doorway entry doesn't have too much use for the writable aspect, but other uses plus the whole learning aspect lead me down that route, and after having 200+ tags on hand it just made since to use them on the doors too.
Even the simple flash memory aspect of NTAG is interesting in some of the uses I've seen.
NTAG 216 has 888 bytes of flash you can use, and all of the NTAG 2xx's lay these out in 8 byte "chunks"
Each chunk has its own flash write circuit in the silicon, aka a "security bit", basically a fuse you can blow after which that 8-byte chunk is no longer writable.
You can also query this fuses state. or even go the long route by trying to write to it and checking if the data changed, before treating the tag as valid.
Of course the smart card features available to NFC are as you say very interesting.
Being able to send a challenge to be used with a private key, without any access to the private key, has been a problem since the start of asymmetric ciphers, and even a decade+ ago was only solved by specialized (and expensive!) HSM devices.
Hell, the NXP SmartMX brand tags not only have factory programed smart card functions but on-board random number generators, which are only a bit over $5 usd each in small batches.
Not the greatest pricing in NFC, but pretty good in my book for just messing around with at home.
It's probably worth noting that quite a few different frequencies are used at the radio level.
At work we use 13.56 mhz RFID tags for some internal inventory counting, with receiver units in the ceiling that can poll almost 200 tags per second in one broadcast.
NTAG uses this same frequency.
But HID 26-bit tends to be in the lower 125 khz frequency. There are others in the UHF range.
I guess it's more like a layer-1 vs layer-4 OSI difference there. Communications vs data formats.
In the hotel comment at the end of my last post, I know of at least one chain that uses Indala brand cards, a proprietary format to serve a similar purpose to HID 26-bit.
The difference is Indala comes with the "facility" ID part burnt in from the factory, and must be specified when ordering and can't be changed afterwards. You're stuck ordering from them forever.
HID 26-bit also provides for separate facility/unique parts of the ID, but both are user writable. Pretty sure it has 24 bits for data, 2 bits for parity one for each "half", but if I recall correctly it specified an 8/16 bit division for those purposes.
And of course one can use those bits anyway you want, though obviously to keep compatibility with other systems you'll certainly want to assume the right 16 bits for the unique ID part.
Some of us have a smaller SSD as C drive...
Wow, C drive, I almost forgot about that. I hope that does not trigger any other ancient, painful memories. How is life, back there in Hell?
Hey now, CP/M and CMS wasn't that bad! It was a perfectly acceptable OS for your 80's multi-architecture and single user needs.
Of course it is strange parent poster didn't use the SSD to replace their A: hard drive.
Gotta really wonder what SSD is being made that is smaller than the C: floppy disk used originally.
Especially seeing as they only replaced the second floppy drive!
And in how many hotels could you use it yet ?
Any that have NFC-capable door locks. I doubt there are many (if any) of those, though, because until this update only Android phones could operate them. Hotels have used Bluetooth for their digital key systems, because it would work with all mobile devices. Not that iPhones are catching up, maybe we'll see hotels switching to NFC.
Personally I was hoping for protocol details, as the question you replied to depends fully on that.
Saying "NFC" is a lot like just saying "barcode" or "magstripe"
There are proverbially hundreds of data encoding standards within each of those, which actually even Android has limitations on regarding its NFC chip too.
For example I use "NTAG" NFC at home, and Android supports the NTAG 215 spec but not* 216 I use.
There's also an NTAG 213 spec but I don't use that or know if Android supports it. Being older I'd assume so but never checked.
*(That's not to say there aren't options, just none "baked in" and easily accessible to apps, or even most users)
As NTAG was made by NXP and not HID, I'm not much expecting Apple to get that one either.
HID is by far the largest provider of RFID and NFC gear.
The HID 26-bit standard is probably the most widely used, as HID Global has essentially allowed its use by anyone for most anything. It's not quite the "open source" of the NFC world, but might be better described as "open licensed freeware".
So while Android's NFC supports more NFC protocols to userland than Apple, and for much longer now, one must in general still be careful throwing out the "all" word.
Even specifically regarding hotels, some got jiped on early proprietary systems that specifically go out of their way to create vendor lock-in, and those poor ignorant souls will very likely not be compatible still.
It would be acceptable to require a desktop computer as an intermediary, but it must be my software that runs on the desktop, not some magical program from who knows what. Is this possible? (I don't think so, but I'd like to be proven wrong.) And don't tell me to just use the AppStore. My application does not meet Apple requirements (it provides for in-app software upgrades).
Check out the "iPhone Configuration Utility" published by Apple (there are win/osx versions)
Since iOS 8 it lets one "side load" an .ipa or an .app bundle to an iPhone.
The former intended mostly for corporations to distribute "enterprise licensed" apps to their fleet of devices, and the latter intended mostly for developers, so with your particular use case falling somewhere in the middle of those it's hard to say if it will be ideal for you.
I use it for provisioning devices at work. Each "profile" you create can be applied to a connected phone, can be remote pushed on pre-registered cells, and generates ".mobileconfig" files that can be delivered to a device via web download, email attachment, etc.
One word of warning, devices not under your own control are going to prompt the user to trust your .mobileconfig certificate and key when being installed by them.
The best I can describe how it looks would be similar to accepting a self-signed https certificate in a browser (before chrome started hiding that ability at least)
Also your app won't have access to any of the AppStore hooks for analytics. If your app doesn't "phone home" (which users tend to hate), you won't even know someone installed it this way.
Being that you specified a closed source program and purchasing from you, it implies to me there may be piracy concerns with this. Not having ever pirated apps, or made apps to be pirated, I can't really expand on how easy or not this is or what can be done on your side, but I figured you'd want to be aware of that.
Also on the end-user trust subject, when you run the config util you'll see a bunch of categories of things the tool can change, similar to windows group policies pushed out to desktops. .mobileconfig file will be listed out when the user is prompted to accept and trust your cert.
But be aware that each category you have setup in your
So don't go thinking you can setup an app install profile along with a "secret" web browser proxy setting profile, to try and trick people into thinking it is just to install your program. They will be informed of the fact a web browser setting profile is there too. .mobileconfigs. If that trust is abused, you'll likely be labeled a malware pusher, evil hacker, or worse.
This tool lets you modify most any setting available to the user, and plenty of settings that are hidden (like cellular carrier profiles), so requires a huge amount of trust from the one making those
I'm not implying anything about you personally here, just throwing that out there.
Android users are used to this sort of permissions abuse and simply avoid you on the play store without complaining much.
Apple users tend to bitch about such things loudly to anyone that will listen. Including reporting such behavior to Apple, which isn't likely to help your "can't get app approved" situation any.
Why wouldn't you be happy to see this in a court of law that examines whether the officer's response was appropriate or not? That's all I'm asking for.
Then perhaps you should have said that instead of saying the exact opposite of that to me.
You said you blame him, the officer. Out right blame him with no court of law, no judging the response, and even misrepresenting the very basis on if it could be appropriate or not.
You explicitly claimed he had no justification, despite a 911 call recording you could have listened to that gives that very justification, and despite the twitter posts showing this was a swatting which makes that justification based on false facts.
You can't have a true or false justification when you outright try to claim there isn't one in the first place.
You explicitly claimed there was nothing to react to, despite the video clearly showing action.
You didn't bother raising any points on if that action justified any reaction at all let alone the one that happened. You outright denied any action having happened.
You are very clearly prejudging the situation and stating it is for reasons other than those presented.
This is not you asking for it to be seen in a court, this is you placing blame.
As for why I myself wouldn't be happy to see the outcome of the court case? Well I guess I wouldn't be happy because I would be happy to see that.
The post of mine you replied to specifically said I didn't blame the victim, and find it hard to blame the cop from what's been released so far.
Elsewhere in this thread which you likely haven't seen, the only blame I lay is on the stupid kid that self-incriminated himself requesting the swat in the first place, and for the potential mystery 3rd kid making the call to 911 for him (assuming that person exists and isn't the same kid)
I'm still not sure what to think of the 1st kid, the one that gave the fake address and egged the others on...
I am. I'd prosecute the cunt for murder, because he just shot an unarmed man with no warning and with no justification.
"Justification" as in being told the person you are being sent to has a weapon, has already killed one person, is holding three others hostage, and has stated to the 911 operator "If you send anyone out I am definitely not putting my gun down"?
"No warning" as in seeing the person described above raise his arm quickly to point straight it at you with a clenched fist?
I think it's pretty hypocritical of you to blame someone for believing exactly what you would believe in the same situation.
I also think it's pretty dishonest of you to say you would in no way have reacted the same either.
Especially with people like yourself that would then blame you for being directly responsible for murdering one or more of your fellow officers by not stopping the shooter.
If you really wish to ignore all the evidence and blame people anyway, I guess that's your call, but don't expect others to not think less of you for it.
Whoever made the call, as well as the officers who couldn't be bothered to Not shoot someone.
And this should be trivial.
The stupid kid that requested the swatting call posted on his twitter account "That house I had swatted is on the news"
The other stupid kid he was arguing with also posted screenshots of his direct message with the first stupid kid, providing the address as his own and telling him to come try something.
Twitter should have all of that logged along with their home or cell IPs, which would lead back to a name on an ISP account with an address.
Their gamer tags were also used and shown, which should similarly point to connection logs with IPs.
Only the 3rd stupid kid who actually placed the 911 call himself may possibly have not left a call or voip trail.
But seeing as this will be a murder charge, and they will soon if not already have in custody the kid requesting the swatting, I highly doubt that kid won't drop the swatters name and info if for no other reason than hoping he gets a less harsh sentence.
You know nothing will happen regarding the cop though.
We know something. If he had done something obviously threatening, the police would be shouting it from the rooftops and releasing all their bodycam footage to provide justification.
When they clam up and give only the fewest details possible, you know they have no excuses.
The body cam video is at the top of the page of the very first link in the summary...
Unless the guy answered the door shouting he was going to kill the cops, or unless he was holding a firearm as he opened the door....
I'm really unsure about that one.
You don't usually wait for the person to finish raising their weapon, train it squarely on you, and open fire, all before you react to defend yourself.
In the half a second or less that it took for the victim to very quickly raise his arm from a downward position to a pointed directly at you position, at that point you have less than a fraction of a second for a trigger to be pulled.
As you can see from the video, the victim raised his arm Very fast to get it to a straight outward pointing at the police position, all in less than half a second.
If the person DID have a gun, then at that moment you have far less than a half of a second of time to react before a trigger is pulled. His fist was clenched as well.
The only way to know for sure at that point that he in fact did not have a gun would be to wait for the shot to not happen, and then wait even longer for him to continue raising his arm upwards (at a slower rate for some reason)
Personally I would have most likely thought the same thing, although it would have been more "I am about to be shot and killed" as I wouldn't have had a weapon on me or trained at the guy to prevent it.
To be clear, I'm not blaming the victim for "putting his hands up" wrong.
What I'm doing is not blaming the officer for believing in that half of a second the person was about to open fire, nor blame the officer for not waiting the tenth of a second or less to hear and see someone get shot or not.
The entire situation was fucked up for everyone that was in it to be in, and even more fucked up after taking into account what caused the situation in the first place.
You are making an assumption on the situation. What we know is that as far as the police knew they were rolling on a murder and hostage situation (hostage in danger of murder as well). We don't know if the potential hostage taker had his hands hidden, whether he made any sharp movements - basically we know nothing. We don't know if the officer followed procedure, or what he was responding to. To say that they just rolled up and shot the first person they saw is only showing your bias and not what was reported.
This is untrue.
The police have released the 911 call audio, a dash camera video, and the body camera video from the police officer who made the shot.
All of this is linked in the article above, specifically the kansas.com news URL.
You can see all of the things you claim "we" don't know.
You can see the victim raising his hands, but then turning sideways and making a stance with his legs that one might do if they are about to angle a weapon on someone. At that moment one of his hands was, from the side view, in the back and not visible.
It does look like, in hindsight, he was attempting to appear unarmed and likely succeeded in doing so for the police that saw him open the door when he was standing face-on.
By the time he was standing sideways however, any officer who just arrived not seeing before this point, including the one who fired, would only see what looks like an intentionally hidden hand being moved in an action one would do if they had a weapon and was about to raise it.
With the fact the shooting officer only had partial information being witnessed, and that partial information does very clearly look like the victim has a weapon, I can't fault that officer for his actions.
Only once you see the footage before that point do you clearly see he is unarmed.
And it's worth noting that all of the officers that were present at that point in time did not open fire, so clearly interpreted what they saw correctly.
You can also play the 911 call audio to answer your question "we" have about what they were responding to.
In Vietnam they fight wrongful views, we're fighting fake news, can someone tell me what the difference is?
Fake news is:
"Nguyen Trong Nghia took his trash out to the street last night at 4PM in pink bunny slippers"
I know that is fake because I just made it up. Even if I'm accidentally right, I intended it to be a comical lie, so it should probably count.
Wrongful view would be:
"Nguyen Trong Nghia took his trash out to the street last night at 4PM in pink bunny slippers"
Where Nguyen claims he did not and does not take out his trash, despite a video I recorded of him doing so in his pink bunny slippers that I posted to Youtube.
Nguyen then has the video taken down and tells his military to kill me so I stop talking about his slippers.
Or at least it would be if I had such a video to post and he cared who I was and any of that above had happened. Which it didn't, but it makes me happy imagining it did :P
As an upside, I wonder how many people will now be picturing this higher up political head taking out his trash wearing pink bunny slippers? I hope it's at least a couple.
PS, Nguyen, please don't have me killed. Buds?
He did not seem to have hurt anyone, but only threatened them (with gun violence too). And he got 3 years worth of meals on the tax payers dime.
Mission accomplished?
Even there he failed at being efficient at the task.
He could have just wrote to the parole board the first time that he hates humanity and wants let out early to get a head start on making everyone pay.
Then he wouldn't have had this period of unemployment to solve, all while still seeming like the go-getter he claims to be!
BGP vs. Root name servers?
I don't know the relationship (if any) between the two, but is it just coincidence this is happening less than a month after this:
No direct relationship, other than DNS servers like all servers have an IP address, and the backbone routers need to know how to get your traffic to said IP.
BGP is how the backbone knows where to send packets to get to the destination.
Normally if you try to go to say Googles web server, the BGP tables list Googles IP space and point to the backbone routers that directly connect (peer) with Googles routers.
In cases of hijacking like this, Russia updated those route tables to say Google is directly connected to one of their own routers, so any packets you send to a Google IP end up going to Russia first.
Then they can do whatever they want, like record it and then pass the packets back to the routers originally listed in BGP before the hijack.
Root DNS servers would be similar, although there are many root DNS servers around the world and any lookups you make tend to semi-randomly pick one from the list for each query.
Another quirk with the root servers is how they are distributed and that they use a logical/physical separation, primarily to be extremely efficient but it can help in cases like this too.
There are 13 "logical" root servers, named with the letters A to M, each for the most part under the control of a different organization/entity.
However for any one of those logical names, there can be many physical servers that answer for it.
They also don't use unicast IP addressing like nearly every server you're used to, but a type of addressing called anycast.
So for example, the "A" server is run by Verisign (from back when they were Internic), and the "E" server is run by NASA.
But "A" actually points to many physical servers distributed around the US.
Anycast provides one IP for each of those many separated servers, and that IP is actually answered by many different networks and ISPs, each having many redundant physical servers to distribute the load over.
Which cluster of servers you get mainly depends on which of those networks is closest to you on the network. So you querying the anycast IP on the west coast will have completely different networks and servers responding than if I queried that same IP on the east cost.
That makes it pretty difficult to hijack in a useful way, and to hijack enough of those routes and servers in a physical area on a single anycast IP, let alone more than one of the server clusters, and let alone again more than one "letter" designated root.
If instead of a USB stick one used something easily readable by a smart phone, the verification part could likely be fully streamlined and automated.
There are plenty of places online you can feed in a wallet hash to query the balance from the blockchain.
I'm just not sure what hardware would be suitable.
Programmable NFC tags I've used hold anywhere from a few bytes up to a couple kb, which wouldn't be enough.
Even things like QR or blot codes weren't really intended to hold a hundred or more KB, not to mention that would be one heck of a QR code!
I suppose for smartphones that support OTG/USB, going with a flash drive would be OK, but it's a bit clunky still.
But scan the root of the removable drive for wallet.dat, verify the checksum, get the hash, and submit to some of those balance checking services. Some basic sanity checking on differing results to show a warning or something would also be useful.
There's got to be a better type of hardware that functions as block storage and can be used with a USB interface and something else more fitting for a mobile to talk to...
Most of that is simply false, and I have proven it myself with HP Compaq, EliteDesk, and EliteBook hardware.
You don't need access inside a network or on the physical machine, it has been proven to "call home" and receive orders much as botnets do, over unblocked HTTP requests.
Etherial shows nothing except ARP traffic while powered off, or powered on in any mode but provisioning mode.
In provisioning mode Etherial shows two TCP connections to my provisioning server, and neither are HTTP.
You can't stop it if it is plugged into a network
Until ME is enabled, it doesn't even perform ARP requests let alone is capable or tries to send packets anywhere.
and all of the benefits you listed already existed in other forms which didn't require a massive multi-million-dollar engineering effort to stick inside the chip undetected for years.
It was never hidden in the chip, you just didn't bother reading Intels documentation, which was publicly available on Intels website since before vPro and ME hit the market.
Yes management cards were available before, but they are equally closed source and not auditable, and cost extra per PC to deploy.
If it were legitimate it would have been public knowledge from the start,
Which is has been.
https://software.intel.com/en-us/articles/intel-active-management-technology-start-here-guide-intel-amt-9
https://www.intel.com/content/www/us/en/software/setup-configuration-software.html
Documentation goes back to 2008 when vPro, the software containing ME, was released.
not a secret projects the alphabet agencies recruited hardware developers for, required top secret clearance to undertake within the Intel team working on it, etc.
Any evidence for that claim? Other than Intels own website and documentation that disproves it was "secret"?
The justifications for the existence of it are like the shills
Oh, damn, wish I saw that sooner before actually providing you with facts you don't care about.
Yes, I use technology, that makes me a shill by your definition.
Continue on with your fantasies, I'll stop ruining them.
Well, that's fucking scary. What is the alleged upside to Intel ME? Asking for a friend...
Mass configuration, deployment, and recovery for a large fleet of desktop computers you are tasks with managing.
You enable ME to remotely control the hardware and provision its boot drive, and manage the initial setup of the OS down for untrained staff for repair purposes.
You can enable it by hitting Control-P at boot, turn ME on, setup an IP/vlan, and upload a public key into it to authenticate.
Alternately you can load some config files on a USB stick to do that, and hitting Control-P will see this and use those configs for you.
Alternately again, if you buy a hundred or more PCs a year, you can provide a special public key and ME-Manager IP address to your OEM, and they put it into a special provisioning mode with that info.
On first boot it will contact your provisioning server and accept configurations sighed with that special keypairs private key, and the provisioning server then uploads the real public key and other settings.
Once provisioned, you can instruct the system to mount an ISO image over the network to be in the optical drives place, and send power on/off events.
Generally you'll do this to load your initial OS base image and let it image the HD for your company.
Once that part completes, the base image OS does its own initial setup depending on OS (Active directory for windows; ldap with puppet for unix or RedHats launchpad as just two examples)
When a desktop has a boot drive failure, you can order a new HD and have it shipped to the branch office, and have nearly anyone swap the HD out.
In the mean time you've reset the system to be in provisioning mode, so you instruct your "remote hands" to change out the HD for the new one and hit the power button.
The system comes up and has the HD imaged again, either with a previous backup, or your base image, and go from there.
The concept is a great one.
However the GP is telling the truth when they say the ME code can't be audited.
That's a pretty big problem as you have to trust Intel that it does what they say it does.
Of course to even get to ME, you need either layer-3 network access or physical access.
If one has physical access they already "own" the system, and already falls under physical security instead.
It's the local LAN access that can be a problem.
The concern in the real world isn't so much about Intel or the government, as those bodies already don't have access into our firewalls nor do we provide them VPN access in. It's about other employees which need to be in the building to do their work and thus have access to the LAN.
GP also intentionally confused the separate issues with taking over the ME code.
Researchers have found code exploits and used those to perform the hijacking of the ME.
There is zero evidence Intel has any additional access than is claimed.
This is like saying a one-off typo in some code that results in a remote exploit in your webserver is the exact same thing as the makers of that webserver intentionally granting someone else access to your system. And that is rarely the case.
As the ME code isn't able to be audited the possibility is not zero percent.
But even if it could be shown Intels code has no backdoors and everything is written to work exactly like the ME documentation says it does, that only means Intel is trustworthy in their intentions. Bugs in code that result in an exploit are still very possible and still a real threat.
I just don't see the usefulness of saying "Looks like a bug in OpenSSH has an exploit, and Linus allowed it to be put on Linux, thusly I will never trust another thing Linus says or writes including any patches to fix the problem" purely due to not being smart enough to understand the math and code doing encryption.
You misunderstand it's just broadcasted to all cells assuming your phone might be on and listening.
Actually I believe you are partially misunderstanding, and parent is correct.
From grandparent:
Your phone could listen for its ID and receive text messages without revealing it's location. Making calls or sending messages would however reveal your location to your carrier.
The existing cellular network does not work via broadcasting messages to all towers such that your phone could passively listen for it.
Your phone registers with the cell tower, which updates the carriers internal routing info, and only then does the network forward things for your cell ID to that one tower you last registered with.
If your phone unregistered, the network will either hold the message or simply reject it as undeliverable.
If your phone registered to a tower and then simply "goes dark" without unregistering, the message will still go to just the last tower you registered with for a little bit to be broadcast there. The tower will retry a number of times until it receives an acknowledgement from your phone, and failing to do so (with the phone not transmitting) typically results in the message being rejected back or simply dropped.
After a few minutes of the phone being dark and not responding to the towers (think like a constant ping check), the route gets removed from the network as stale, and then even that one tower no longer transmits anything to your cell.
To have a cell network operate on a true broadcast without acknowledgement type of basis, it would need redesigned from the protocol up.
This would be much closer to "possible" on a home-grown newly designed cellular network/protocol, such as this article is about.
But the bold part of the quote above indicates GP was specifically talking about your carriers cell network, not a newly made one that works in a different way such as this.
Negative. I assume you meant to reply to the person a few posts up who mentioned the 50 foot cable?
I'm also wondering how this person is routing their trips to avoid superchargers.
I live in a fairly sizable city with over a two million population count.
We currently have one supercharger fairly far south.
I live on the south west part of town and that supercharger is still a 15 minute drive from me away from the city center.
We do have one more scheduled to be built on the far north side, but won't be completed until the end of 2018.
I work roughly in the middle west or as many say slightly into the north west. The planned supercharger would be 20 or so minutes away (actually closer to 35-40 in rush hour traffic) from work and in the opposite direction from my home.
So the only special routing I need to do to avoid superchargers is to basically drive anywhere whatsoever except in one direction out on one of 8 highways.
Now there are other non supercharger stations around, and not nearly as out of the way.
But at least a few months ago last I checked, on my route home to work, there were zero public charging stations. For fairness that would be compared to 3 gas stations along the two routes I can take.
My typical weekly grocery shopping routes would take be by more non superchargers and regular gas stations as well. And there are enough around town that any non-typical route I may take to get to some specific place would probably be fine. In fact I seriously doubt I would need to charge up while out running around so long as I leave home on a full charge.
Please note I'm not trying to frame this as any sort of problem for me. Personally supercharge stations wouldn't likely even come into play for me unless I'm taking a trip outside of the city.
Most of my charging would need to be done at home only, and with my normal driving routines that would be more than enough for my home-to-work route and my home-to-shopping routes.
But my point is you don't need to do any special work to "avoid" superchargers, it just naturally happens when you don't do special work to seek them out.
Why is nobody claiming I'm Satoshi?
Hell, gimme a hundred or two of those bitcoins and I'll call you whatever you want :P
Why do they need to shout "Hey, here are all the access points that I have connected to in the past"?
It's part of the spec, not so much wifi specifically but DHCP and DNA protocols.
The idea was when you first connect to a wifi network, you use ARP at layer 2 and broadcast a DHCP request to get a valid IP to begin using layer 3.
When you are disconnected "briefly" and reconnect later, that IP is likely to still be valid for use.
Using DNA (direct network attachment), you can broadcast the previously used router MAC, device MAC, and SSID to verify you are on the same local link, and can begin reusing your previous IP without having to wait for a DHCP renewal.
If you send an ARP with the remembered MACs, and get a reply, something else is now on the IP you had and you must renew with DHCP to get another IP.
If you don't get a reply, its generally safe to assume it.
I presume it was assumed this would be a common and desired situation. Walking around in and out of wifi range, or maybe allowing the radio to go into a sleep mode where it basically is off and thus detached from the network, this does let you reconnect a bit faster.
I also presume the security implications were just not thought of or cared about.
https://www.ietf.org/rfc/rfc4436.txt
Is this how it works? My understanding that tracking cookies will be a) multi-domain and b) will also include add network domain. For example, Taboola cookie would be still accessible across all sites that use Taboola. Is this not the case?
That is the case in IE, but in all other browsers no, a cookie can only be set for a domain if sent by a server on that domain.
But look at slashdot as an example. When you go to slashdot.org, you are loading content from 4 separate host/domains.
slashdot.org can set a cookie that gets sent back to slashdot.org
But you are also loading content from other domains:
a.fsdn.com content is loaded and can set a cookie, which gets sent back to a.fsdn.com
gstatic.com content is loaded and can set a cookie, which gets sent back to gstatic.com
etc
If you went to another website owned by FSDN but isn't slashdot, odds are that site will also load content from a.fsdn.com and thus that domains cookie will be sent back to a.fsdn.com again.
In this way a.fsdn.com can track you over all of the websites that load its content in, be it slashdot or freshmeat or whatever.
Now add in the fact that most websites these days load content from the google ad network, or facebook, or twitter.
Each of those sites can set a cookie on their content and it gets sent back when visiting any other website that also loads content from them.
This is how facebook and such track you over most of the Internet, even if you never do or have visited facebook.com directly. It's almost guaranteed however that you have loaded content from facebook.com indirectly, and your browser happily sends the facebook cookies back to facebook.
What this feature does is tag a cookie not just with the domain of the sending web server, but also with the domain in your address bar.
That means the facebook cookie as loaded from slashdot is stored separately from the facebook cookie from random-other-site.
Revisiting slashdot will only send the facebook cookie set with the slashdot domain, not the facebook cookie set by the random-other-site domain.
A nice set of standards guidelines being published by an official body for how and when numbers get whitelisted would be very useful too.
I don't think it should cost any extra to do this on top of the existing service costs, but actually performing good verification and forcing carriers to allow a means to do that would go very far.
Our voip system I manage at work is one of those that technically "spoofs" caller ID, however only using DIDs we have registered.
Not all of our phones have public DIDs, we call them "Internal Only phones", however those extensions always present our reception desk / main number in caller ID, so it is at least possible to route an incoming call back into the building, even if that routing is done manually by a human.
However we also have three separate SIP trunk providers for outbound calls, and only one of those routes DIDs in to us. We have another forth SIP provider for the other half of our incoming DIDs, and due to their pricing we don't use them for outbound at all.
Currently those outbound only providers have no method to verify our DIDs belong to us, since they don't have access to the registries of the inbound providers who publish those DIDs.
This needs fixed way further up in the chain.
Also another reason for the guidelines mentioned above is because we would in essence need to whitelist two blocks of DIDs (1499 numbers in total, don't ask) with all 4 service providers, and again 2 of those 4 have no idea what our DIDs are and no way to verify them.
It would truly suck for each provider to have their own little, and different, white list process.
So long as the rules to white list are all the same, we would know any changes accepted by one would be accepted by all of them.
This is also part of why a white list fee per number isn't particularly reasonable. I'd be going through that process four separate times, multiplied by basically 1500 numbers would be 6000 line-item style charges. Even at one dollar that is an annoying thing to deal with, but multiplied by whatever dollar amount you had in mind could easily push it into the realm of ridiculous.
Much more reasonable would be to charge a set amount per verification process.
For the vast majority of us with larger blocks of numbers, this would be a one-time process when starting service, and likely not have to change for years.
Obviously for whichever service is actually routing newly requested DIDs to you that they serve out of their pool, no verification is needed simply because they already know. If I'm purchasing another 200 DIDs from provider A, it will be A that assigns them to us and should count as verified. Only providers B and so on would need to do any extra work for that.
This way it would push the burden onto those companies that are frequently changing their DIDs and numbers around often, which at first glance are the very companies causing these problems in the first place.
I think the "digital" logo on this story isn't quite what you think it's for.
These pills are wired to a VAX by an RS232 cable hanging out of your butt. :P
The article wanted to skim over that detail, for obvious reasons
Care to explain how this story has anything to do with copyright in general or Steam in particular?
Dunno what he is referring to about Steam, but as far as copyright goes this story (and millions more) are quite relative to copyright protection and theft from us the public.
In order to get copyright protection, that protection comes with a cost.
Problem #1 is that now our Government forces copyright, and paying that cost, on everyone by default. This shouldn't be.
But the cost that is required to pay in exchange for that copyright protection, is that after a limited time that copyright ends and the public gets the right to do anything with the work they want.
Problem #2 is that "limited time" is now a hundred years after the author dies, which arguably isn't all that limited. But:
Problem #3 is that even after the insanely huge time given as "limited", that cost is still expected to be paid in exchange for giving you that copyright protection.
Again that cost is that the public gains the right to do anything they want with that work.
Companies locking up their work behind encryption, and/or keeping a portion of that work on their own servers, completely negates the possibility for that cost to be paid.
They are intentionally trying to prevent the payment to the public they owe for the copyright protection they are stealing for free.
This is no different from me intentionally writing you a bad check to pay you for that car you are selling.
And not just intentionally writing a bad check that you are unaware of the fact it is bad, but hand drawing a check picture on a napkin signed with a drawing of a middle finger made out for $0, so you KNOW beyond any shadow of a doubt I have no intent on paying you the asking price of that car.
Except the government will force you to still give me that car, basically for free.
Holding parts of the software back intentionally so it won't function, so it can not be given to the public as the payment for copyright protection requires, is no less fraud than the check example above.
Now, what would you do in the above example if I handed you such an obviously fake check you realized wouldn't be good, and literally all of my actions state I refuse to pay you?
You wouldn't give me that car for free, would you?
This is what is meant by we should no longer be even entertaining the idea of granting copyright protection to such companies.
Except if I don't respect the copyright protection they are stealing from us for free and without payment, WE get punished.
IE if you didn't give me that car for free in exchange for my silly money check made out to "fuck you", the government would forcibly take that car from you to give to me.
How fair is that?
It isn't.
And that is the root of the complaint about copyright law as it currently stands.