Can I use the .ag top level domain (TLD) on Heroku? Where can I find information on Heroku TLD limits, if there are any?
Context: I've been looking into the world of custom TLDs and found that non-standard ones aren't available for sale as widely as a typical .com is, even for ones assigned to identify specific countries like .ag is. This makes me extra cautious about moving forward with claiming the one I want. It's also more expensive than a .com, so "just wait and see" isn't the ideal solution for figuring this out. This TLD is especially convenient because I'd like to use it for a short links app, and the domain name I want to create is short and will have a clear association with my brand.
Research: I read Heroku's documentation on adding domain names. All of the examples are .com. There's also some Heroku documentation on browser security and cookies that discusses TLDs, including some that identify a country. I got the impression from the two sources that I can claim any domain that's not already claimed, but I'm still not sure about if there are any technical concerns I should be aware of beforehand.
I should also mention, I didn't see any error when I added the domain to Heroku (before purchasing it).
I have a problem that it's bugging me:
I have some iBeacon devices (tags to be exact) and I want to create a custom new app supporting their functionality.
The problem is that every now and then the tags change their mac address (very frequently) as well as their UUID (frequently but not too frequently). The way I see it this feature has been implemented to protect users against tracking.
Now this can be hardware specific feature (I use the lasso tags) or be a standard functionality of the standard (iBeacon spec which I don't have).
Can someone please verify the intended functionality or at least give pointers to iBeacon official specification and/or other documents?
Regards
Recently, Apple made the iBeacon specification available on their iBeacon Developer pages: https://developer.apple.com/ibeacon/ (the "Download Artwork and Specification" link in the right-hand sidebar). You still need to accept the iBeacon License Agreement.
Some vendors use rotating UUIDs (and/or majors and minors) as a way to address security and privacy concerns, just like you said. It's not exactly what Apple intended for iBeacon (they mentioned on multiple occasions that you should plan around the possibility of beacons being spoofed, b/c iBeacon is not meant to be secure), but it's still compatible with the specification.
Most commonly, there's some known seed or secret key uploaded to the beacon during manufacturing or when enabling such security feature. Only authorized parties know the seed/key, and thus can either predict what's the UUID/major/minor of a beacon supposed to be at any given time, or decrypt it. In the end, UUID+major+minor is just 20 bytes of data broadcast by the beacon, and you can encrypt it just like any other data. (Well, actually, the problem with the iBeacon is that on the iOS side, you need to know the UUID of the beacon in order to scan for it, so at least the UUID—i.e., the first 16 bytes—need to be only pseudo-random, and can't be completely random.)
Personally, I would say this is one of the cases where the market validated the iBeacon idea/spec, and came up with a solution to a problem that Apple decided not to tackle. And I wouldn't blame them—they pretty much pioneered the beacon technology (sure, it was there before, but much less popular than it is today), and nobody at that time though about using iBeacon for tagging personal belongings.
When Google released Eddystone—i.e., an alternative beacon protocol—earlier this year, they announced at the very same time that encrypting the Eddystone identifiers will be part of the core spec:
At the same time, privacy and security are really important, so we built in a feature called Ephemeral Identifiers (EIDs) which change frequently, and allow only authorized clients to decode them. EIDs will enable you to securely do things like find your luggage once you get off the plane or find your lost keys. We’ll publish the technical specs of this design soon.
(source: http://googledevelopers.blogspot.com/2015/07/lighting-way-with-ble-beacons.html)
To me, this pretty much validates the idea of securing beacons, and rotating the UUIDs is just a clever market/community "hack" of the iBeacon spec to do just that.
Bluetooth LE beacons transmitting the iBeacon format, including those displaying the iBeacon certification logo, typically do not change their mac address. I base this statement on two years of experience testing these beacons from a wide variety of vendors. It is also unusual for an iBeacon to automatically change its ProximityUUID. These appear to be peculiarities that are specific to one vendor's implementation. The fact that these implementation details are unusual doesn't necessarily mean it isn't allowed -- it just means it is unusual.
Unfortunately, the iBeacon specification is proprietary and not publicly available from Apple. You need to enter a business relationship with Apple to be able to access the official documentation. That said, there is no shortage of information about iBeacons in the public domain obtained by folks who have reverse engineered the simple devices. In the absence of official public documentation, you simply have to do Google searches and use your judgement about the quality of the information you find.
I would like to develop an application that can connect to server and uniquely identify clients then give them permissions to run a specific query on server's database.
How can I identify clients in a unique way. Is MAC address reliable enough? or should I use something like CPU id or something else?
clarification : I do not what to create a registration code for my app. As it's suppose to be a free application. I would want to detect each client by an id and decide which one could have the permissions to run a specific method on server or not.
The usual approach is to give each client a login (name + password). That way, it's easy to replace clients when they need upgrade or when they fail.
MAC address should be unique but there is no central registry which enforces this rule. There are also tools to change it, so it's only somewhat reliable.
CPU and HD IDs are harder to change but people will come complaining when their hard disk died or when they upgrade their system.
Many PCs have TPM modules which have their own IDs but they can be disabled and the IDs can be wiped. Also, there are privacy issues (people don't like it when software automatically tracks them).
Another problem with an automated ID approach is how to identify them on the server. When several clients connect for the first time in quick succession, you will have trouble to tell them apart.
This question appears to have already been asked and answered in detail (although, you may not like the answers, since they appear to add up to: it's problematic.) I agree with Xefan's comment that more details would help define your question. Here's a link to earlier discussion on this:
What is a good unique PC identifier?
Short: I am looking for a very simple (configuration/maintenance wise) solution, that would allow to collect user-feedback/bug-reports from my apps/web-sites over the internet.
Long:
Right now I have very simple web-app written using ASP.NET MVC that receives http-post requests at http://localhost/feedback and saves them as c:\temp\{guid}-feedback.txt. I used UltiDev HttpVpn (BTW it's very cool) to expose this page to the internet without having to put my app in DMZ. I collect following information (through a feedback form in the app, or a web-site's feedback page): user name, e-mail, type of the message (feature request, bug report, comment), application name (hard-coded in the app that sends the feedback), and message-text/comment.
About E-mail:
E-mail is not good enough, since there will be no e-mail client on most of the computers my apps are running at (also, it takes too many clicks to send an e-mail).
About JIRA:
IMHO JIRA is too heavy for what I need. I might be wrong, since I have never installed/configured it myself. Does it have a http-post interface (so I can put my own interface on)?
.NET on Windows solution preferred
FREE is a requirement
To my opinion http://www.useresponse.com is a nice alternative to SaaS services (will be once released on December 2011) you can install on your site and customize up to your satisfaction (both look and functionality).
Commercial, though. Don't think you'll have enough functionality from free scripts (neither support and new features).
Worth checking out FogBugz. I used it many versions ago and it has changed a lot since then.
But it allows you to report app crashes / bugs, etc. through a number of mechanisms (see link for details): http://www.fogcreek.com/FogBUGZ/LearnMore.html?section=NewPlatform#hist_PullCases
Update: this question is specifically about protecting (encipher / obfuscate) the content client side vs. doing it before transmission from the server. What are the pros / cons on going in an approach like itune's one - in which the files aren't ciphered / obfuscated before transmission.
As I added in my note in the original question, there are contracts in place that we need to comply to (as its the case for most services that implement drm). We push for drm free, and most content providers deals are on it, but that doesn't free us of obligations already in place.
I recently read some information regarding how itunes / fairplay approaches drm, and didn't expect to see the server actually serves the files without any protection.
The quote in this answer seems to capture the spirit of the issue.
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to use.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
An extra bit of info: client environment is adobe air, multiple content types involved (music, video, flash apps, images).
So, is it reasonable to do like itune's fairplay and protect the media client side.
Note: I think unbreakable DRM is an unsolvable problem and as most looking for an answer to this, the need for it relates to it already being in a contract with content providers ... in the likes of reasonable best effort.
I think you might be missing something here. Users hate, hate, hate, HATE DRM. That's why no media company ever gets any traction when they try to use it.
The kicker here is that the contract says "reasonable best effort", and I haven't the faintest idea of what that will mean in a court of law.
What you want to do is make your client happy with the DRM you put on. I don't know what your client thinks DRM is, can do, costs in resources, or if your client is actually aware that DRM can be really annoying. You would have to answer that. You can try to educate the client, but that could be seen as trying to explain away substandard work.
If the client is not happy, the next fallback position is to get paid without litigation, and for that to happen, the contract has to be reasonably clear. Unfortunately, "reasonable best effort" isn't clear, so you might wind up in court. You may be able to renegotiate parts of the contract in the client's favor, or you may not.
If all else fails, you hope to win the court case.
I am not a lawyer, and this is not legal advice. I do see this as more of a question of expectations and possible legal interpretation than a technical question. I don't think we can help you here. You should consult with a lawyer who specializes in this sort of thing, and I don't even know what speciality to recommend. If you're in the US, call your local Bar Association and ask for a referral.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
Files being tied to the user requires some method of verifying that there is a user. What happens when your verification server goes down (or is discontinued, as Wal-Mart did)?
There is no level of DRM that doesn't affect at least some "honest users".
Data can be copied
As long as client hardware, standalone, can not distinguish between a "good" and a "bad" copy, you will end up limiting all general copies, and copy mechanisms. Most DRM companies deal with this fact by a telling me how much this technology sets me free. Almost as if people would start to believe when they hear the same thing often enough...
Code can't be protected on the client. Protecting code on the server is a largely solved problem. Protecting code on the client isn't. All current approaches come with stingy restrictions.
Impact works in subtle ways. At the very least, you have the additional cost of implementing client-side-DRM (and all follow-up cost, including the horde of "DMCA"-shouting lawyer gorillas) It is hard to prove that you will offset this cost with the increased revenue.
It's not just about code and crypto. Once you implement client-side DRM, you unleash a chain of events in Marketing, Public Relations and Legal. A long as they don't stop to alienate users, you don't need to bother.
To answer the question "is it reasonable", you have to be clear when you use the word "protect" what you're trying to protect against...
For example, are you trying to:
authorized users from using their downloaded content via your app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
authorized users from using their downloaded content via any app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
unauthorized users from using content received from authorized users via your app?
unauthorized users from using content received from authorized users via any app?
known users from accessing unpurchased/unauthorized content from the media library on your server via your app?
known users from accessing unpurchased/unauthorized content from the media library on your server via any app?
unknown users from accessing the media library on your server via your app?
unknown users from accessing the media library on your server via any app?
etc...
"Any app" in the above can include things like:
other player programs designed to interoperate/cooperate with your site (e.g. for flickr)
programs designed to convert content to other formats, possibly non-DRM formats
hostile programs designed to
From the article you linked, you can start to see some of the possible limitations of applying the DRM client-side...
The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.
The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.
Neither of these approaches required breaking the DRM being applied, or even hacking any of the products involved; they could be done simply by passively observing the protocols involved, and then imitating them.
So the question becomes: are you trying to protect against these kinds of attack?
If yes, then client-applied DRM is not reasonable.
If no (for example, you're only concerned about people using your app, like Apple/iTunes does), then it might be.
(repeat this process for every situation you can think of. If the adig nswer is always either "client-applied DRM will protect me" or "I'm not trying to protect against this situation", then using client-applied DRM is resonable.)
Note that for the last four of my examples, while DRM would protect against those situations as a side-effect, it's not the best place to enforce those restrictions. Those kinds of restrictions are best applied on the server in the login/authorization process.
If the server serves the content without protection, it's because the encryption is per-client.
That being said, wireshark will foil your best-laid plans.
Encryption alone is usually just as good as sending a boolean telling you if you're allowed to use the content, since the bypass is usually just changing the input/output to one encryption API call...
You want to use heavy binary obfuscation on the client side if you want the protection to literally hold for more than 5 minutes. Using decryption on the client side, make sure the data cannot be replayed and that the only way to bypass the system is to reverse engineer the entire binary protection scheme. Properly done, this will stop all the kids.
On another note, if this is a product to be run on an operating system, don't use processor specific or operating system specific anomalies such as the Windows PEB/TEB/syscalls and processor bugs, those will only make the program even less portable than DRM already is.
Oh and to answer the question title: No. It's a waste of time and money, and will make your product not work on my hardened Linux system.