Voxel
President of Progress City
No actually you need a fastpass+ for the bathroom.
http://www.vineroulette.com/v/Wait-times-and-FastPass-DisneySideContest-hdad0K3mb7F
-
Welcome to the WDWMAGIC.COM Forums!
Please take a look around, and feel free to sign up and join the community.
MiceAge on the latest news regarding MyMagic+ : Read it and weep.
- Thread starter marni1971
- Start date
No actually you need a fastpass+ for the bathroom.
http://www.vineroulette.com/v/Wait-times-and-FastPass-DisneySideContest-hdad0K3mb7F
ToTBellHop
Well-Known Member
The problem is that withouth 12000 FP+ spots for Spaceship Earth, there would not be enough to go around for everyone to get 3 selections. They'd be FP+ing the parking shuttle and the talking drinking fountain. Oh wait, that's gone.
Cesar R M
Well-Known Member
Speaking of the bands.
Do you think the bands have information in them stored or they are just an identification number that connects to a database using Disney's own network?
Id honestly suggest something like "just reserve 30 minutes every 4 hours exclusively for fast pass members.." in mayor attractions.
Example..
9:00am entry is just for fastpass members, once the the line is cleared of these clients.. the fastpass line is closed and the normal line is opened..
at 1:45pm the normal line closes, and the fast pass line opens.. once the normal line is cleared.. the fastpass start to get in at the scheduled hour.
The point is using escalated hours exclusive to FastPass (different ones in each mayor attractions) that benefit the fastpass hours..
Example..
Attraction A as 9:00 am, Attraction B as 10:00am.. Attraction C as 11:00am and so on.. (no more than 4 attractions having the same fastpass hour so they can control where the people with fastpass move.. aka effective crowd control)
Last edited by a moderator:
Voxel
President of Progress City
I believed someone pulled the information contained on a band a few months ago and it was just a name and a identification number in an XML format. The other information was for the sensors. The entire thing is held in the back end I believe when it comes to personal information
Disneyhead'71
Well-Known Member
That's the best part of FP+. At least you'll be sure you get to ride before you leave home.
FigmentJedi
Well-Known Member
There hasn't been a Disney Store in Iowa in over ten years.
ford91exploder
Resident Curmudgeon
Agree or even one of the DCL ships and put some of the implementation team on the ship so they could have observed FIRST HAND problems with system, The positioning of hands, slow reads etc all could have been handled early in the process.
ford91exploder
Resident Curmudgeon
Your idea actually makes sense - which of course is why it will not be adopted by TWDC.
Voxel
President of Progress City
Exactly. This would have been the logical moves. Every major MMO or game console or even phone release should have told Disney that a mass roll out like this is costly and problematic without the proper testing. I am surprised they didn't get help from Apple or Amazon in development/testing this system.
spacemt354
Chili's
Just to clarify on this if it hasn't been already. If we are so paranoid about CMs having personal information about the guests in the parks...where they are, what they go on most, etc...then the same type of fear should be applied for social networking.
Someone could post on Facebook "Going on Soarin'" and now that information is readily available to a lot more people than just a CM. Instagram. Posting a picture of Epcot from a certain location. Cell phone, snap chat, all sorts of ways in which your personal information can be sent anywhere and to anyone.
My family and I had a horrible experience with MM+, but I can't get too freaked out about this when people give away their personal info every day on social networking and don't even think twice about it. There are other aspects of Next Gen that need to be fixed/overhauled before I get paranoid that a CM knows what ride I'm on.
Voxel
President of Progress City
Also to better answer the question of whats contained in a MM+ band:
Any valued information has been X'ed out in parts.
This was found here http://www.disboards.com/showthread.php?t=3171483
Any valued information has been X'ed out in parts.
Code:
<?xml version="1.0" encoding="UTF-8"?>
<scan>
<version>2.00</version>
<date>2013-09-12</date>
<title>NXP Semiconductors MIFARE DESFire EV1 tag</title>
<uid nxp="true">04:4D:35:XX:XX:XX:XX</uid>
<hasndef>false</hasndef>
<section>
<subsection title="IC manufacturer">
<block type="text">
<content>NXP Semiconductors</content>
</block>
</subsection>
<subsection title="IC type">
<block type="text">
<content>MIFARE DESFire EV1</content>
</block>
</subsection>
<subsection title="DESFire Applications">
<block type="text">
<content>Access control data for electronic locks #0
¶ Timelox AB<hexoutput> (0xF70090)</hexoutput>
and 1 unknown application<hexoutput>:
¶ Unknown application 0x78E127</hexoutput></content>
</block>
</subsection>
</section>
<section>
<subsection title="No NFC data set storage">
<block type="text">
<content></content>
</block>
</subsection>
</section>
<section>
<subsection title="Memory information">
<block type="text">
<content>Size: 0
kB
Available: 320 bytes</content>
</block>
</subsection>
<subsection title="IC detailed information">
<block type="text">
<content>Capacitance: 70
pF</content>
</block>
</subsection>
<subsection title="Version information">
<block type="text">
<content>Vendor ID: NXP<hexoutput> (0x04)</hexoutput>
Hardware info:
¶ Type/subtype: 0x01/0x02
¶ Version: 1.0
¶ Storage size: 512 bytes<hexoutput> (0x12)</hexoutput>
¶ Protocol: ISO/IEC 14443-2 and -3<hexoutput> (0x05)</hexoutput>
Software info:
¶ Type/subtype: 0x01/0x01
¶ Version: 1.4
¶ Storage size: 512 bytes<hexoutput> (0x12)</hexoutput>
¶ Protocol: ISO/IEC 14443-3 and -4<hexoutput> (0x05)</hexoutput>
Batch no: 0xBA3494XXXX
Production date: week 24, 2012<hexoutput> (0x2412)</hexoutput></content>
</block>
</subsection>
</section>
<section>
<subsection title="Technologies supported">
<block type="text">
<content>ISO/IEC 7816-4 compatible
Native DESFire APDU framing
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible</content>
</block>
</subsection>
<subsection title="Android technology information">
<block type="text">
<content>Tag description:
¶ TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA]
android.nfc.tech.IsoDep
¶ Maximum transceive length: 261 bytes
¶ Default maximum transceive time-out: 1000
ms
¶ Extended length APDUs not supported
android.nfc.tech.NfcA
¶ Maximum transceive length: 253 bytes
¶ Default maximum transceive time-out: 1000
ms
No MIFARE Classic support present in Android</content>
</block>
</subsection>
<subsection title="Detailed protocol information">
<block type="text">
<content>ID: 04:4D:35:XX:XX:XX:XX
ATQA: 0x4403
SAK: 0x20
ATS: 0x0675778102XXXX
¶ Max. accepted frame size: 64 bytes (FSCI: 5)
¶ Supported receive rates:
" 106, 212, 424, 848
kbit/s (DR: 1, 2, 4, 8)
¶ Supported send rates:
" 106, 212, 424, 848
kbit/s (DS: 1, 2, 4, 8)
¶ Different send and receive rates supported
¶ SFGT: 604.1
µs (SFGI: 1)
¶ FWT: 77.33
ms (FWI: 8)
¶ NAD not supported
¶ CID supported
¶ Historical bytes: 0x80 |·|</content>
</block>
</subsection>
<subsection title="Memory content">
<block type="text">
<content>PICC level (Application ID 0x000000)
¶ PICC key configuration:<hexoutput> (0x0F01)</hexoutput>
" AES key
" PICC key changeable
" PICC key required for:
~ directory list access: no
~ create/delete applications: no
" Configuration changeable
" PICC key version: 254</content>
</block>
<block type="text">
<content>
Application ID 0xF70090
¶ Key configuration:<hexoutput> (0x0B83)</hexoutput>
" 3 AES keys
" Master key changeable
" Master key required for:
~ directory list access: no
~ create/delete files: yes
" Configuration changeable
" Master key required for changing a key
" Key versions:
~ Master key: 0
~ Key #1: 0
~ Key #2: 0</content>
</block>
<block type="text">
<content>¶ 1 file present</content>
</block>
<block type="text">
<content>
" File ID 0x00: Standard data, 128 bytes
~ Communication: encrypted
~ Read key: master key
~ Write key: master key
~ Read/Write key: master key
~ Change key: master key</content>
</block>
<block type="text">
<content> ~ (No access)</content>
</block>
<block type="text">
<content>
Application ID 0x78E127
¶ Key configuration:<hexoutput> (0x0B82)</hexoutput>
" 2 AES keys
" Master key changeable
" Master key required for:
~ directory list access: no
~ create/delete files: yes
" Configuration changeable
" Master key required for changing a key
" Key versions:
~ Master key: 1
~ Key #1: 1</content>
</block>
<block type="text">
<content>¶ 2 files present</content>
</block>
<block type="text">
<content>
" File ID 0x01: Standard data, 16 bytes
~ Communication: plain
~ Read key: free access
~ Write key: free access
~ Read/Write key: blocked
~ Change key: free access</content>
</block>
<block type="text">
<content> ~ Contents:
</content>
</block>
<block type="DesFire">
<address addrwidth="4">0</address>
<data>68 8C 1F 00 00 00 00 00 05 FB 00 05 XX XX XX XX</data>
</block>
<block type="text">
<content>
" File ID 0x02: Standard data, 56 bytes
~ Communication: plain
~ Read key: key #1
~ Write key: free access
~ Read/Write key: blocked
~ Change key: free access</content>
</block>
<block type="text">
<content> ~ (No access)</content>
</block>
</subsection>
</section>
</scan>This was found here http://www.disboards.com/showthread.php?t=3171483
spacemt354
Chili's
I agree. No longer news nor rumor. I'm not a fan of MM+, but bashing it on bogus charges just for the sake of bashing it I don't understand.
CDavid
Well-Known Member
The difference is that it is up to me what *I* choose to post on social networking; A running update of my daily activities is not automatically uploaded. I can post a picture or comment when and if I want and decide who gets to see it (within social network privacy restrictions, or lack thereof). Access of such information remains pretty firmly under my control, because I don't have to share a single thing.
Voxel
President of Progress City
From my understanding, much of this information is information Disney has been obtaining for years from guest.
flynnibus
Premium Member
Like one of the posters in that thread mentioned - this is only one of the chips in the band. The guy didn't post the contents of the other chip.
Cesar R M
Well-Known Member
You know, I wonder if you could actually make a generator that mimics and bruteforces the magic band XML data and thus "extract" the information the server sends of the client.
I wonder if the exchange is always password protected by the client pin or a employee pin.
Voxel
President of Progress City
This is the reason they implement the passcode system of a 4 digit pin. I think of a few of us forget to realize that the same information could be pulled from the old Passes given to guest staying on hotel property. If someone go close enough to you they could scan the information.
The other chips are actually not memory chips but what appear to be possibly 1 bluetooth chip and 2 Rfid chips. This give the band multiple functionality. The low distance bluetooth and rfid chip would most likely be used for admission and transactions, where as the long distance RFID will be for logging guest movements (How many guest go to the restroom, whats the most popular path way,i.e.). Everything posted is what is physically stored on memory the other data on the other chips have nothing to do with guest information and probably deal with communication protocols.
flynnibus
Premium Member
You have things all mixed up. There are two RFID chips (one HF, and one UHF), and then the 2.4GHz radio.. which is spoken of as if it's Bluetooth, but no one has confirmed that. The 2.4GHz radio would be the one used for detection at range since it's the active radio and is published as communicating with the wireless infrastructure. The RFID tags are for the contact systems or short/area detection (they are passive tags that require radiating to detect). The only thing posted in that dump is just the information from the HF radio tag. The UHF tag would be encoded with data as well... as well as the 2.4GHz radio broadcasting something unique (else.. both are pointless).
There is no specific reason for personal info to be on any of these (and makes life difficult in manufacturing and provisioning them) - but the dump from above is not a complete picture at all.
Voxel
President of Progress City
Thank you for correcting me. I knew I was mostly current with the chips but I am bad at the difference between HF and UHF, and other aspects.
spacemt354
Chili's
Same with MM+. you have the option to participate or not. If the privacy concerns are so paramount to people, then they shouldn't participate. A debate can be had regarding how much you'll be at a disadvantage for not participating, but there is no debate on the fact that MM+ is optional, just like posting on a social network.